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Preface 


This  document  was  prepared  by  the  Institute  for  Defense  Analyses  (IDA)  for  the 
Office  of  the  Deputy  Director,  Systems  Engineering  in  the  Directorate  of  Test,  Systems 
Engineering  and  Evaluation  under  the  Office  of  the  Under  Secretary  of  Defense  for 
Acquisition  and  Technology.  As  specified  in  the  task  titled  Acquisition  Case  Studies,  an 
objective  of  the  task  was  to  provide  lessons  learned  from  a  defense  program  using 
advanced  acquisition  and  development  methods,  including  the  use  of  Integrated  Product 
and  Process  Development  (IPPD)  and  Integrated  Product  Teams  (IPTs).  This  case  study 
will  be  used  by  the  sponsor  to  help  train  the  DoD  acquisition  community  on  the  use  of 
these  key  concepts. 

t 

The  case  study  is  a  companion  document  to  an  earlier  IDA  study.  The  F/A-18  E/F: 

An  Integrated  Product  Team  (IPT)  Case  Study.  The  first  case  study  captured  the  lessons 
learned  by  the  Navy  acquisition  office  when  implementing  IPTs,  whereas  this  second 
case  study  captures  lessons  learned  from  implementing  IPPD  as  viewed  from  the 
perspective  of  the  prime  contractor  McDonnell  Douglas  Corporation  (MDC). 

MDC  personnel  showed  a  sincere  interest  in  the  case  study  and  were  extremely 
generous  with  their  time,  providing  access  to  key  personnel  from  multiple  disciplines.  A 
special  acknowledgement  is  due  to  Mr.  Jim  Young,  Division  Director,  F/A-18  IPT 
Engineering.  He  made  many  of  his  staff  available  for  interviews  and  met  with  us  a  second 
time  in  Patuxent  River,  Maryland.  A  special  thanks  is  also  due  to  Mr.  Mike  Biggs, 

Program  Engineering,  E/F  Technical  Integration,  who  answered  many  questions  as  we 
wrote  the  case  study  and  provided  us  with  follow-up  material. 

This  document  was  reviewed  by  Mr.  Mark  D.  Schaeffer  and  Mr.  Thomas  J.  Parry  of 
Systems  Engineering,  Directorate  of  Test,  Systems  Engineering  and  Evaluation.  It  was 
also  reviewed  by  Dr.  Richard  J.  Ivanetich,  Dr.  Danny  L.  Reed,  Dr.  Karen  J.  Richter,  and  * 

Dr.  Steven  P.  Wartik  of  IDA.  In  addition,  the  following  MDC  people  shared  their 
experience  with  us  through  presentations  and/or  interviews  and  deserve  our  thanks. 
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Executive  Summary 


Overview 

This  case  study  documents  how  McDonnell  Douglas  Corporation  (MDC)  used  an 
Integrated  Product  and  Process  Development  (IPPD)  management  philosophy  to  design 
and  produce  the  F/A-18E/F  aircraft.  The  paper  identifies  key  IPPD  principles  and 
provides  examples  of  how  they  were  implemented  by  MDC.  It  examines  the  management 
practices,  organization  structure,  and  integrated  tools  used  to  foster  the  program’s 
success.  For  students  of  the  acquisition  process  in  the  Department  of  Defense  (DoD),  a 
list  of  discussion  items  and  sample  answers  is  provided. 

« 

The  F/A-18E/F  program  was  selected  as  the  subject  of  the  case  study  due  to  its 
achievements.  In  prior  years,  cancellation  of  three  of  the  Navy’s  tactical  aircraft 
programs,  the  A- 12,  A-X,  and  the  Navy  Advanced  Tactical  Fighter,  had  rendered  the  F/A- 
18  the  Navy’s  only  active  tactical  aircraft  program.  As  such,  it  had  a  crucial  role  in  naval 
air  planning.  Successful  transition  of  the  F/A-18E/F  to  full  production,  with  particular 
attention  to  schedule,  cost,  and  risk,  was  therefore  vitally  important  to  the  Navy.  In  1991- 
1992,  well  before  IPPD  and  Integrated  Product  Teams  (IPTs)  became  DoD  policy,  the 
program’s  achievements  were  recognized  by  DoD’s  first  Acquisition  Excellence  Award. 
Dr.  Paul  Kaminski,  the  Under  Secretary  of  Defense  for  Acquisition  and  Technology, 
noted  the  program’s  use  of  IPTs  and  continuous  sharing  of  information  as  key  factors  in 
the  program’s  achievements. 

The  material  for  the  case  study  evolved  out  of  a  two-day  visit  by  a  study  team  from 
the  Institute  for  Defense  Analyses  (EDA)  to  the  MDC’s  St.  Louis  facility  in  Missouri.  It 
captures  the  practices  and  benefits  of  EPPD  as  reported  by  the  contractor;  they  were  not 
independently  verified  by  the  study  team.  This  case  study  is  a  companion  to  an  earlier 
IDA  case  study1,  written  from  the  perspective  of  the  Navy  program  office,  that  traces  the 
use  of  EPTs  within  the  government  acquisition  office.  The  objective  of  these  case  studies 
was  to  document  lessons  learned  from  DoD  programs  using  advanced  acquisition  and 
development  methods  such  as  IPPD  and  EPT. 

IPPD  Implementation  on  F/A-18E/F  Program 

IPPD  is  a  management  technique  that  simultaneously  integrates  all  essential 
acquisition  activities  through  the  use  of  multidisciplinary  teams  to  optimize  the  design, 
manufacturing,  and  supportability  processes.  IPPD  facilitates  meeting  cost,  schedule,  and 
performance  objectives  from  product  concept  though  production,  including  field  support. 


1  Bailey,  Elizabeth  K.  and  Beth  Springsteen.  The  F/A-18  E/F:  An  Integrated  Product  Team  (IPT)  Case 
Study.  Alexandria,  VA:  Institute  for  Defense  Analyses,  April  9,  1998. 
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Several  key  concepts  and  principles  inherent  to  IPPD  were  critical  to  the  effective 
implementation  on  the  F/A-18E/F  program:  customer  focus,  concurrent  development  of 
processes  and  products,  multidisciplinary  teamwork,  proactive  identification  and 
management  of  risk,  and  integrated  information  environment. 

Customer  focus  is  used  to  identify  and  to  satisfy  the  customer’s  needs  better,  faster, 
and  cheaper  by  including  the  customer  in  decision  making  and  on  multidisciplinary 
teams.  From  the  beginning  of  the  F/A-18  program,  strong  customer  focus,  including 
frequent  and  open  communications  between  MDC  and  the  customer,  enabled  the  E/F  to 
be  an  affordable  evolution  from  the  C/D  and  not  become  a  “gold-plated”  program. 

Concurrent  development  of  products  and  processes  helps  ensure  that  the  product 
design  does  not  drive  an  unnecessarily  costly,  complicated,  or  unworkable  supporting 
process  when  the  product  is  produced  and  fielded.  Processes  are  developed  concurrently 
with  the  products  they  support.  By  tailoring  the  design  of  the  E/F  to  take  maximum 
advantage  of  the  manufacturing  process,  the  E/F  has  42%  fewer  parts  than  the  C/D  even 
though  it  is  25%  larger.  Moreover,  the  F/A-18E/F  program  was  able  to  reduce  production 
costs,  defects,  and  rework  by  creating  production  processes  and  hardware  designs 
simultaneously  and  carefully  analyzing  the  sources  of  variation  in  the  process. 

Multidisciplinary  teams  comprise  members  from  technical,  cost,  manufacturing,  and 
support  organizations,  including  both  customers  and  suppliers.  These  team  members  are 
empowered  to  make  decisions  for  their  respective  organizations  and  to  keep  them 
informed  of  the  product  and  process  decisions.  On  the  F/A-18E/F  program,  schedule,  and 
technical  parameters  were  allocated  down  to  Level  5  of  the  Work  Breakdown  Structure 
(WBS),  equipping  teams  to  do  their  jobs.  Moreover,  team  leaders  were  given  the 
appropriate  authority  over  product,  process,  and  personnel  to  get  the  jobs  done.  Weekly 
reporting  of  metrics  kept  teams  informed  and  accountable.  Organizational  structure 
mirrored  product  structure,  enabling  the  team  structure  to  evolve  with  the  life  cycle. 
Finally,  skills  of  team  leaders  were  critical  to  the  success  of  teams. 

A  proactive  approach  for  identifying  and  managing  risk  areas  is  also  critical  to  the 
successful  implementation  of  IPPD.  MDC  uses  an  organized,  comprehensive,  and 
iterative  process  for  identifying  and  analyzing  cost,  technical,  and  schedule  risks  and 
instituting  risk-handling  options.  Even  though  risk  was  minimized  from  the  outset 
because  the  F/A-18E/F  had  evolved  from  the  C/D  program,  risk  was  still  an  important 
concern.  Proactive  identification  was  accomplished  through  the  overarching 
management  philosophy  of  recognizing  problems  early  on  (through  weekly  reporting 
mechanisms)  and  asking  for  help.  Once  system  requirements  were  allocated  to  teams,  the 
teams  then  used  a  formal  risk  management  process  to  identify  risks,  analyze  them  in 
terms  of  their  likelihood  and  consequence,  develop  a  risk  management  plan,  and  execute 
the  plan  to  mitigate  the  risk.  In  this  way,  team  leaders  were  able  to  identify  tasks  on  the 
critical  path  and  then  work  aggressively  to  execute  them  so  as  not  to  hold  up  the  program. 

An  integrated  information  environment  relates  requirements,  planning,  resource 
allocation,  execution,  and  program  tracking  over  the  product’s  life.  It  helps  to  ensure  that 
teams  have  all  available  information,  thereby  enhancing  team  decision-making  at  all 
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levels.  HometWEB  is  MDC’s  secure  intranet  information  system  that  provides  MDC,  the 
subcontractors,  and  the  Navy  program  office  real-time  access  to  technical  and  business 
information.  Integrated  Management  Information  Control  System  is  MDC’s  standard 
system  for  measuring  and  reporting  progress  at  all  levels.  It  enabled  open  communication 
and  rigorous  risk  management  to  occur  on  the  F/A-18  program  by  providing  accurate, 
detailed  progress  measurements.  Mod  SDF  is  a  collection  of  common  database  and 
analysis  tools  used  to  facilitate  the  exchange  of  engineering  information  across  the 
product  and  technology  teams. 

Conclusions 

IPPD  enabled  the  F/A-18E/F  program  to  meet  its  budget  goals  and  be  ahead  of 
schedule  with  an  air  vehicle  that  was  well  below  its  specified  weight.  It  ist  an 
improvement  over  the  F/A-18C/D  in  nearly  every  measure,  including  reliability, 
maintainability,  range,  survivability,  weapons  carriage  capability,  mission  flexibility,  and 
future  avionics  expandability.  MDC  reports  that  implementation  of  IPPD  principles  was 
key  to  the  program’s  success. 
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Chapter  1.  Introduction 


This  case  study  examines  the  use  of  Integrated  Product  and  Process  Development 
(IPPD)  in  the  design  and  production  of  the  Navy’s  F/A-18E/F  tactical  aircraft.  The 
events  leading  to  and  surrounding  the  F/A-18E/F  program  created  an  environment  that 
placed  a  premium  on  open  communication,  affordability,  adherence  to  schedule,  and 
proactive  risk  management.  This  study  examines  how  the  F/A-18  program  team  at 
McDonnell  Douglas  Corporation  (MDC)  responded  to  these  priorities  using  an  IPPD 
management  philosophy  supported  by  an  Integrated  Product  Teams  (IPTs)  organizational 
structure.  It  describes  practices  and  benefits  as  reported  by  the  contractor;  the  study  team 
from  the  Institute  for  Defense  Analyses  (IDA)  did  not  perform  an  independent  assessment 
to  verify  these  practices  and  benefits. 

This  paper  is  a  companion  to  an  earlier  EDA  case  study,  written  from  the  perspective 
of  the  Navy  program  office,  that  traces  the  use  of  EPTs  within  the  government  acquisition 
office.2  The  purpose  of  both  case  studies  was  to  document  lessons  learned  from  DoD 
programs  using  advanced  acquisition  and  development  methods  such  as  IPPD  and  IPT. 

In  this  case  study,  we  focus  on  the  application  of  various  EPPD  concepts  and 
principles  to  the  F/A-18E/F  development  process.  The  material  for  the  case  study 
evolved  out  of  a  two-day  visit  by  the  authors  to  the  contractor’s  St.  Louis  facility  in 
Missouri.  A  follow-up  meeting  was  held  in  late  August  at  the  Navy’s  Patuxent  River 
location  in  Maryland.  It  is  noteworthy  that  their  use  of  IPPD  and  of  EPTs  began  in  the 
1991-1992  timeframe,  well  before  these  practices  became  DoD  policy.3  The  E/F  model 
makes  for  an  especially  interesting  case  study  because  it  represents  an  evolution  from  the 
earlier  C/D  model:  thus  we  have  a  built-in  point  of  comparison  with  the  old  way  of 
building  military  aircraft. 

We  refer  to  the  F/A-18  prime  contractor  as  MDC,  reflecting  the  name  of  the  company 
at  the  time  of  most  events  described  in  the  study.  But  in  August  of  1997,  the  Boeing 
Company  purchased,  which,  in  turn,  became  part  of  a  Boeing  Company  business  unit 
known  as  the  Military  Aircraft  and  Missiles  Group.  The  F/A-18E/F  is  now  the  Boeing 
F/A-18E/F  Super  Hornet. 

The  outline  of  the  case  study  contains  10  chapters.  Chapter  2  presents  the 
background  of  the  F/A-18E/F  program.  Chapter  3  introduces  five  key  IPPD  principles: 
customer  focus;  concurrent  development  of  products  and  processes;  multidisciplinary 
teamwork;  proactive  identification  and  management  of  risk;  and  integrated  information 


2  Bailey,  Elizabeth  K.  and  Beth  Springsteen.  The  F/A-18E/F:  An  Integrated  Product  Team  (IPT)  Case 
Study.  Alexandria,  VA:  Institute  for  Defense  Analyses,  April  9,  1998. 

3  On  May  10,  1995,  the  Secretary  of  Defense  William  J.  Perry  directed  the  “immediate  implementation” 
of  IPPD  throughout  the  acquisition  process  to  the  maximum  extent  possible.  Memorandum,  Use  of 
Integrated  Product  and  Process  Development  and  Integrated  Product  Teams  in  DoD  Acquisition. 
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environment.  Chapters  4  through  8  are  rich  with  examples  showing  how  the  F/A-18E/F 
program  applied  each  of  these  concepts  and  principles.  Chapter  9  contains  conclusions. 
Chapter  10  contains  discussion  items  of  interest  to  students  of  the  DoD  acquisition 
process.  Appendix  A  contains  example  responses  to  each  discussion  item.  A  list  of 
acronyms  is  provided  at  the  end. 
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Chapter  2.  F/A-18E/F  Program  Background 


The  F/A-18E/F  is  a  twin-engine  aircraft  designed  to  fly  from  the  Navy’s  aircraft 
carriers  to  perform  both  air-to-air  and  air-to-ground  combat  missions.  The  prime 
contractor  is  MDC.  Northrop  Grumman  as  the  principle  subcontractor  builds  the  aft 
fuselage.  General  Electric  is  responsible  for  the  engines.  The  E/F  is  an  evolutionary 
design  derived  from  the  F/A-18C/D  now  in  service.  It  is  approximately  25%  larger  than 
its  predecessor,  has  35%  more  engine  thrust  and  weighs  30%  more  at  maximum  gross 
takeoff  weight.4  The  E  version  carries  a  crew  of  one,  while  the  F  version  is  a  two-seat 
configuration.  Both  versions  can  carry  a  wide  variety  of  air-to-air  and  air-to-ground 
weapons  on  eight  wing  stations  and  on  three  fuselage  locations. 

i 

The  program  entered  engineering  and  manufacturing  development  in  1992  and 
passed  Critical  Design  Review  in  1994.  Five  E  versions  and  two  F  versions  are  now 
conducting  flight  testing,  and  the  program  has  entered  low  rate  initial  production. 


Courtesy  of  the  McDonnell  Douglas  Corporation. 


Figure  1.  F/A-18E/F  Super  Hornet 

The  F/A-18E/F  is  the  Navy’s  only  active  tactical  aircraft  program,  and  will  eventually 
perform  most  of  the  Service’s  air  combat  functions  at  least  until  the  arrival  of  the  multi¬ 
service  Joint  Strike  Fighter,  which  is  still  more  than  ten  years  away.  The  program 


4  See  the  U.S.  Navy’s  Navy  Fact  File  on  the  F/A-18  Hornet  at  http://www.chinfo.navy.mil/navpalib/ 
factfile/aircraft/air-fal  8.html. 
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reached  this  position  by  weathering  turbulent  years  that  included  the  cancellation  of  three 
of  the  Navy’s  tactical  aircraft  programs,  the  A- 12,  A-X,  and  NATF. 

As  the  only  remaining  tactical  aircraft  program,  the  F/A-18E/F  assumed  a  crucial  role 
in  naval  air  planning.  Successful  transition  of  the  F/A-18E/F  to  full  production  was 
therefore  vitally  important  to  the  Navy.  Modernization  was  essential  for  both  combat 
effectiveness  and  operational  affordability  because  the  existing  fleet  of  C/Ds  consisted  of 
aging  aircraft  with  limited  options  for  capability  improvement.  However,  in  the  wake  of 
the  A- 12,  A-X  and  NATF  cancellations,  Congress  had  mandated  that  the  E/F  could  not 
exceed  the  cost  of  the  C/D  by  more  than  25%.  Moreover,  the  Navy’s  reputation  as  an 
agency  capable  of  effective  aircraft  procurement  was  at  stake.  In  hearings  on  the  not-yet- 
cancelled  A-X,  Senator  John  Glenn  had  said,  “The  Navy’s  ability  to  manage  such  a 
program  is  atrocious.”5  Congressional  sentiments  like  these  helped  focus  the  Navy’s 
attention  on  schedule,  cost,  and  risk. 

In  1991,  McDonnell  Douglas  sent  a  letter  to  the  Navy  program  office  explicitly 
stating  its  intention  to  place  a  priority  on  open  communication  and  risk  management,  and 
to  use  IPPD  to  achieve  its  cost  and  schedule  goals.6  The  program’s  fidelity  to  these 
intentions  and  its  overall  success  were  marked  by  the  award  of  the  DoD’s  first 
Acquisition  Excellence  Award  by  Dr.  Paul  Kaminski,  then  the  Under  Secretary  of 
Defense  for  Acquisition  and  Technology.  Dr.  Kaminski  noted  the  program’s  use  of  IPTs 
and  continuous  sharing  of  information  as  key  factors  in  the  program’s  achievements.7  In 
the  chapters  that  follow,  this  case  study  examines  the  program’s  IPPD  management 
philosophy  and  the  organizational  structure  and  tools  that  support  it. 


5  F/A-18  Hornet  Overtaking  A-6,  F-14,  Navy  Times ,  January  27,  1992. 

6  F/A-18E/F  Integrated  Technical  Program,  MDC  91B0416,  Volume  II,  Book  1,  page  iv. 

7  F/A-l  8E/F  Receives  DoD  Acquisition  Excellence  Award,  PR  Ncwswire  Association,  March  8,  1996. 
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Chapter  3.  IPPD  Principles 


As  described  in  the  DoD  IPPD  Handbook,  IPPD  is  designed  to  reduce  costs  and 
improve  products  by  making  early  decisions  that  include  inputs  from  stakeholders 
representing  all  elements  of  the  system  life  cycle.8  By  making  decisions  and  changes 
early  in  the  development  phase,  a  program  can  reduce  changes  in  the  later  and  more 
expensive  production  and  support  phases  of  the  program. 

A  program  using  IPPD  also  designs  processes  concurrently  with  the  hardware  that 
will  be  constructed  or  maintained  by  those  processes.  This  concurrent  development  is 
intended  to  reduce  costs  by  balancing  the  needs  of  the  product  and  the  processes 
associated  with  it. 

Multidisciplinary  teams  are  also  a  critical  element  of  the  IPPD  process  because  they 
bring  the  various  stakeholders  together  on  teams,  and  because  they  provide  the  structure 
and  accountability  that  allows  proper  tradeoff  studies  to  be  performed. 

IPPD  was  critical  to  the  success  of  the  F/A-18E/F.  Five  key  principles  described  in 
the  DoD  IPPD  Handbook  were  essential  to  the  effective  implementation  of  IPPD  on  the 
F/A-18E/F  program: 

•  Customer  Focus:  The  primary  objective  of  IPPD  is  to  identify  and  satisfy  the 
customer’s  needs  better,  faster,  and  cheaper.  This  is  accomplished  by 
including  the  customer  in  decision  making  and  on  multidisciplinary  teams 
throughout  the  entire  development  process. 

•  Concurrent  Development  of  Products  and  Processes:  Processes  should  be 
developed  concurrently  with  the  products  they  support  to  ensure  that  the 
product  design  does  not  drive  an  unnecessarily  costly,  complicated,  or 
unworkable  process  when  the  product  is  produced  and  fielded. 

•  Multidisciplinary  Teamwork:  Multidisciplinary  teamwork  is  implemented 
through  the  use  of  IPTs.  Teams  comprise  members  from  technical,  cost, 
manufacturing  and  support  functions  and  organizations,  including  customers 
and  suppliers.  Team  members  are  empowered  to  make  decisions  for  their 
respective  organizations  as  well  as  keep  them  informed  of  the  product  and 
process  decisions. 


8  DoD  Integrated  Product  and  Process  Development  Handbook,  Office  of  the  Deputy  Director,  Systems 
Engineering  in  the  Department  of  Test,  Systems  Engineering  and  Evaluation  under  the  Office  of  the 
Under  Secretary  of  Defense  for  Acquisition  and  Technology,  Washington,  DC,  page  4.  Available  at 
http://www.acq.osd.mil/te/programs/se/ippd/ippd_pubs.html. 
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•  Proactive  Identification  and  Management  of  Risk:  Risk  management  in 
support  of  IPPD  includes  the  use  of  an  organized,  comprehensive,  and 
iterative  approach  for  identifying  and  analyzing  cost,  technical,  and  schedule 
risks,  and  instituting  risk-handling  options  to  control  critical  risk  areas. 

•  Integrated  Information  Environment:  A  seamless  information  environment  is 
used  for  requirements  identification,  planning,  resource  allocation,  execution 
and  program  tracking  over  the  product’s  lifecycle.  This  ensures  that  teams 
have  all  available  information,  enhancing  team  decision-making  at  all  levels. 

The  following  chapters  discuss  in  more  detail  how  each  of  these  IPPD  concepts  were 
implemented  in  the  F/A-18E/F  program. 
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Chapter  4.  Customer  Focus 


A  key  principle  of  IPPD  includes  a  strong  customer  focus.  The  Navy  Program  Office 
has  had  a  very  active  role  throughout  the  entire  F/A-18E/F  life  cycle.  Every  person  from 
the  contractor  team  with  responsibility  on  the  program  has  a  customer  counterpart  with 
whom  he  talks  daily.  Customer  involvement  throughout  the  program’s  life  cycle  was 
evident  during  the  “Twelve  days  of  August”  when  requirements  were  being  defined,  and 
during  Developmental  Test  and  Evaluation  (DT&E)  with  the  Navy’s  involvement  on  the 
Integrated  Test  Team  (ITT). 

4.1  Twelve  Days  of  August 

In  early  August,  1991,  Captain  Craig  E.  Steidle,  the  Navy  Program  Manager  for  the 
F/A-18,  held  a  “mini  program  review”  of  the  proposed  concept  for  the  E/F.  During  the 
nine  months  prior  to  this  review,  teams  from  MDC,  Northrop,  General  Electric,  and  the 
Navy  had  been  working  to  define  the  configuration  and  high-level  requirements  for  the 
E/F.  When  they  came  together  for  the  review,  it  was  clear  that  there  was  no  agreement 
across  teams.  In  the  words  of  Jim  Young,  MDC’s  Integrated  Product  Team  Manager: 

Everybody  was  protecting  their  own  rice  bowls.  The  electronic  warfare 
team  wanted  the  best  of  the  best.  The  low  observables  team  wanted  the 
most  stealthy  aircraft  possible.  The  cockpit  displays  team  wanted  the  very 
best  and  so  on.  The  result  was  a  weapon  system  that  was  over  weight  and 
over  cost.  Captain  Steidle’s  conclusion  during  this  review  was  that  “We 
don’t  have  a  program  here.  What  we  have  is  a  mess.” 

Larry  Lemke  was  the  MDC  Vice  President  and  General  Manager  of  the  F/A-18  at  that 
time.  He  and  Captain  Steidle  worked  throughout  the  night  outlining  what  they  thought 
had  to  be  the  next  steps  if  there  was  to  be  a  viable  E/F  program.  In  Jim  Young’s  words: 

They  decided  to  bring  together  people  who  were  knowledgeable  in  all  the 
many  areas  needed  to  define  the  E/F  configuration  and  high-level 
requirements.  So  they  convened  a  twelve-day  meeting  in  St.  Louis  which 
began  the  following  Tuesday  and  ended  a  week  later  on  a  Friday.  The 
Navy  had  35  to  40  people  at  that  twelve-day  meeting.  There  were  also 
people  from  MDC,  Northrop  and  General  Electric.  The  idea  was  that  at 
the  end  of  the  twelve  days,  they  would  either  have  a  viable,  affordable 
program  or  there  would  be  no  program. 

At  the  beginning  of  the  twelve  days,  Captain  Steidle,  along  with  Mike  Sears,  MDC’s 
Deputy  F/A-18  Program  Manager,  outlined  for  everyone  the  high-level  objectives  for  the 
E/F.  In  comparison  to  the  F/A-18C/D,  the  E/F  had  to  have: 

•  more  range  (fly  farther  without  refueling). 
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improved  survivability. 


•  more  bring  back  (weight  of  stores  that  could  be  brought  back  and  landed  on  a 
carrier), 

•  more  carriage  capability  (could  carry  more  bombs  to  a  target),  and 

•  more  growth  capability  built  in  (extra  physical  space  for  future  growth). 

Captain  Steidle  instructed  everyone  at  the  meeting  that  these  were  the  essential 
objectives  against  which  tradeoffs  would  be  made.  However,  because  Congress  mandated 
that  the  E/F  could  not  exceed  costs  of  the  C/D  by  more  than  25%,  a  different  approach 
was  called  for.  In  Jim  Young’s  words: 

Before  this  meeting,  the  approach  was  to  throw  everything  on  the  table 
and  see  what  it  cost.  This  time,  affordability  was  an  issue.  Each  group  was 
tasked  to  think  about  what  could  be  done  differently.  Given  the  high-level 
objectives  of  the  E/F,  we  were  asked  to  identify  what  has  to  be  in  the 
aircraft  and  what  wasn’t  essential.  We  were  told  to  question  the  what  and 
the  how  of  everything  we  did.  What  could  we  do  to  reduce  weight  and 
cost  without  impacting  the  high-level  requirements? 

During  the  twelve  days,  the  teams  would  convene  at  the  beginning  and  end  of  each 
day.  Otherwise,  each  team  worked  their  area.  Over  the  twelve  days  they  had  to  trade  off 
weight,  fuel  capacity,  volume,  materials,  the  size  of  the  radar  cross-section  (RCS),  and 
cost.  Operational  analysis  was  going  on  throughout  all  of  this  in  order  to  understand  what 
was  being  gained  at  a  system  level  with  the  changes  that  the  teams  were  making.  It  was 
during  this  period  that  the  concept  for  the  Navy-contractor  ITT  during  DT&E  emerged. 
(The  ITT  is  described  in  more  detail  in  Section  4.2.)  Northrop  proposed  changes  to  the 
bulkhead  that  resulted  in  a  large  weight  savings.  MDC  proposed  savings  by  going  with  a 
modest  avionics  upgrade  in  which  90%  of  the  avionics  were  common  with  the  C/D. 

At  the  end  of  twelve  days,  the  basic  air  vehicle  requirements  were  in  place.  In  Jim 
Young’s  words: 

This  was  a  focused  effort  to  define  the  configuration  so  we  could  proceed 
to  the  next  step.  We  came  out  of  it  with  something  that  was  good  enough 
to  be  costed.  And  it  brought  everyone  along  at  the  same  time  (customer 
and  contractor).  We  came  out  with  a  very  clear  direction.  There  was  not 
much  debate  after  that  about  what  was  in  the  aircraft.  But  we  still  had  to 
guard  against  requirements  creep. 

In  the  fall  of  1991,  MDC,  Northrop,  and  GE  worked  with  Naval  Air  (NAVAIR) 
Systems  Command  to  flesh  out  the  requirements.  As  Jim  Young  described  it: 

We  had  a  “spec  jamboree.”  We  broke  into  the  same  teams.  We  took  the 
requirements  and  the  configuration  from  the  twelve  days  and  used  the  C/D 
spec  as  a  starting  point.  We  took  that  specification  apart  and  re-  assembled 
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it  to  reflect  the  E/F  we  had  defined.  Where  there  were  still  disagreements, 
they  were  noted,  and  assigned  to  teams  for  resolution.  Most  of  these  were 
closed  in  the  next  couple  of  weeks.  With  this  process,  we  were  able  to 
hammer  out  the  important  details  of  the  E/F  specification,  include  input 
from  a  wide  range  of  stakeholders,  and  do  it  in  a  very  short  time 

During  these  twelve  days,  the  E/F  changed  from  something  that  was  “gold-plated” 
and  over  cost  to  something  that  represented  an  affordable  evolution  from  the  C/D.  This 
was  achieved  by  maintaining  a  customer  focus  and  making  appropriate  tradeoffs.  This  set 
the  stage  for  success. 

4.2  Integrated  Test  Team 

i 

In  addition  to  being  involved  during  requirements  analysis,  the  customer  played  an 
active  role  throughout  the  life  cycle  as  illustrated  by  their  participation  on  the  ITT.  Both 
the  Navy  and  MDC  personnel  point  to  the  structure  of  the  ITT  as  an  innovation  of  the 
F/A-18E/F  program.  It  was  a  big  step  forward  in  facilitating  more  effective  DT&E  while 
at  the  same  time  saving  money  and  time.  ITT  had  its  origins  as  a  concept  during  the 
“Twelve  days  of  August”  (discussed  previously  in  Section  4.1).  It  had  been  described  in 
detail  in  the  earlier  IDA  case  study,  and  only  a  few  additional  remarks  are  needed.  Jim 
Young  expressed  much  of  the  value  of  the  ITT  from  a  cost  perspective: 

In  the  old  days,  DT&E  took  four  years.  The  contractor  flew  the  plane  for 
two  years,  then  the  Navy  flew  it  for  two  years,  and  then  it  was  turned  over 
for  OT&E.  With  the  ITT,  both  the  Navy  and  the  contractor  fly  their 
development  tests  and  share  data.  DT&E  has  been  reduced  from  four 
years  to  three  years. 

One  important  cost  driver  is  how  fast  we  can  incorporate  changes  into  the 
fleet.  The  lead  OT&E  test  pilot  is  part  of  the  ITT  team  and,  hence,  is 
participating  in  DT&E.  The  objective  of  DT&E  is  to  test  the  weapon 
system  against  the  specifications  and  especially  to  test  the  limits  of  the 
performance  envelope.  In  contrast,  the  OT&E  pilots  don’t  care  what  the 
spec  says.  Their  job  is  to  evaluate  the  plane  from  the  perspective  of 
carrying  out  their  missions.  It’s  really  been  valuable  to  have  the  lead 
OT&E  pilot  on  the  ITT  because  he’s  been  able  to  tell  us  what  is  critical 
about  any  performance  problems  from  a  mission  perspective.  We’ve  made 
improvements  already  based  on  his  input.  This  saves  money  because  the 
earlier  we  make  changes,  the  less  expensive  they  are. 

Jim  Martin,  MDC’s  F/A-18  Manager  for  Test  and  Evaluation,  made  the  point  that  a 
great  deal  of  time  and  effort  went  into  defining  the  Navy’s  and  the  contractors’  role  and 
responsibilities  for  the  ITT. 

A  Memorandum  of  Agreement  (MOA)  was  used  to  define  the 
responsibilities,  structure,  authority,  and  concept  of  operation  for  the  ITT. 

The  MOA  was  fleshed  out  with  ITT  Standard  Operating  Procedures.  It 
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was  approved  by  the  Navy  F/A-18  Program  Manager,  MDC’s  Vice 
President  and  NAVAIR  functional  organizations.  The  MOA  took  three 
years  to  produce.  Every  Navy  slot  in  the  ITT  organization  chart  was 
originally  filled  by  an  MDC  person.  The  Navy  people  are  not  just 
shadows.  They  are  fully  participating  members  of  the  test  team. 

The  structure  of  the  ITT  illustrates  how  the  customer  needs  are  identified  early  and 
how  the  customer  remains  effectively  engaged  in  the  decision  making  process. 
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Chapter  5.  Concurrent  Development  of  Products  and  Processes 


Concurrent  development  of  products  and  processes,  a  second  key  principle  of  IPPD, 
refers  to  the  “simultaneous  development  of  the  deliverable  product  and  all  of  the 
processes  necessary  to  make  the  product.”9  It  is  critical  that  the  processes  used  to 
manage,  develop,  manufacture,  verify,  test,  deploy,  operate,  support,  train  people,  and 
eventually  dispose  of  the  product  be  considered  during  product  design  and  development. 
Early  integration  of  design  elements  can  result  in  lower  costs  by  requiring  fewer  costly 
changes  late  in  the  development  process.  Four  examples  from  the  F/A-18E/F  program 
illustrate  this  principle:  part  count  reduction,  variability  control,  wing  design,  and  flight 
control  computer  system.  Each  is  discussed  in  more  detail  in  the  following  subsections. 

i 

5.1  Part  Count  Reduction 

The  E/F  airframe  had  42%  fewer  parts  than  its  C/D  predecessor  even  though  the 
airframe  is  approximately  25%  larger.  This  part  count  reduction  during  design  was 
achieved  largely  through  consideration  of  high  speed  machining  which  allowed  large 
complex  parts  to  be  machined  from  one  piece  of  stock  rather  than  assembled  from  a  large 
number  of  smaller  parts.  By  reducing  part  count,  costs  from  many  sources  are  reduced. 
This  includes  the  obvious  costs  of  part  assembly,  such  as  tooling,  fastener  installation, 
and  inspection,  as  well  as  less  obvious  costs  such  as  part  tracking,  and  procurement. 

The  high  speed  machining  process  uses  high  spindle  speeds  and  high  feed  rates, 
usually  making  shallower  cuts  than  traditional  machining.  The  shallower  cuts  and  high 
feed  rates  prevent  heat  build-up  that  can  cause  thin  parts  to  warp.  This  warping  had 
previously  made  it  impractical  to  machine  the  thin  webs  typical  of  aircraft  structure,  and 
therefore  made  it  impossible  to  machine  many  of  an  aircraft’s  large  complex  parts.  10 

To  reduce  part  count  and  cost  using  this  new  machining  technology,  the  MDC  product 
teams  tailored  the  design  to  take  maximum  advantage  of  the  new  technology.  The  IPTs 
searched  the  airframe  for  part  count  reduction  opportunities,  asking: 

•  Do  parts  move  relative  to  each  other? 

•  Do  the  parts  need  to  be  made  from  different  materials? 

•  Do  parts  need  to  be  removable? 


9  DoD  Integrated  Product  and  Process  Development  Handbook ,  Office  of  the  Under  Secretary  of 
Defense  (Acquisition  and  Technology),  Washington,  DC,  page  4.  Available  at  http://www.acq.osd. 
mil/te/programs/se/ippd/  ippd_pubs.html. 

10  Proctor,  Paul,  High-Performance  Machining  Provides  Efficiency  Gains,  Aviation  Week  and  Space 
Technology ,  24  August,  1998. 
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If  none  of  these  answers  was  yes,  high  speed  machining,  rather  than  multi-part 
assembly,  was  an  option.  The  answers  to  these  questions  clearly  required  the  inputs  from 
strength  engineers,  maintainability  engineers,  producibility  engineers  and  tooling 
engineers,  among  others.  The  IPPD  philosophy  and  the  IPT  structure  brought  these 
experts  together  early  in  the  design  process,  allowing  these  decisions  to  be  made. 


5.2  Variability  Control 

In  another  example  of  concurrently  designing  products  and  processes,  the  E/F 
program  reduced  costs  and  improved  quality  by  creating  production  processes  that 
reduced  defects  and  rework.  This  reduction  was  achieved  by  creating  the  production 
processes  and  hardware  designs  simultaneously,  and  carefully  analyzing  the  sources  of 
variation  using  a  process  called  Variation  Simulation  Analysis  (VSA).  IPPD  and  IfTs 
were  critical  to  this  analysis.  For  VSA  to  be  used  effectively,  the  tooling,  manufacturing, 
assembly,  and  design  engineers  had  to  interact  early  in  the  development  process,  and 
make  tradeoffs  between  their  disciplines. 

VSA  analyzes  an  assembly  by  statistically  combining  the  variations  created  in  each 
phase  of  the  manufacturing  process.  These  variation  sources  include  items  such  as  the 
tolerances  on  the  individual  part  drawings,  the  tolerances  on  the  tooling  drawings,  and  the 
capabilities  of  the  various  assembly  operations.  Each  of  these  sources  creates  a  mean 
result,  and  variation  around  that  mean.  A  hole  drilling  operation,  for  example,  may  create 
a  mean  hole  diameter  of  0.250  inches,  but  will  sometimes  create  0.245  inch  holes,  while 
at  other  times  creating  0.255  inch  holes.  When  this  variation  is  combined  with  tolerances 
in  the  tool  that  holds  the  part  before  assembly  with  the  mating  part,  and  with  variation  in 
the  fastener  diameter,  a  combination  of  random  variables  is  created.  VSA  uses  Monte 
Carlo  simulation,  which  is  a  statistical  combination  of  a  series  of  random  variations,  to 
predict  the  percentage  of  time  that  the  final  assembly  will  fall  within  the  requirements.  A 
sample  VSA  output  is  shown  in  Figure  2  on  the  next  page  . 

Figure  2  shows  an  assembly  that  will  be  out  of  specification  limits  over  12%  of  the 
time.  Because  the  VSA  analysis  is  done  early  in  the  design  process,  the  IPT  can  evaluate 
corrective  options  ranging  from  revised  tooling  to  revised  tolerances  on  some  component 
in  the  assembly  to  changes  in  the  design.  It  is  also  possible  to  change  the  specified 
allowable  variation  because  a  multi-disciplinary  team  can  evaluate  the  effect  this  change 
will  have  on  system  requirements.  In  a  serial  design  approach,  this  analysis,  if  it  was 
performed  at  all,  would  have  occurred  later  in  the  process,  perhaps  only  after  production 
began  and  assembly  problems  surfaced.  At  that  point,  design  changes  are  difficult  and 
expensive. 

When  MDC  had  applied  VSA  as  part  of  the  IPPD  approach,  it  found  that  roughly  half 
of  the  original  concepts  required  only  minor  optimization,  while  one  quarter  required 
changes  to  the  tooling  concept,  and  another  quarter  required  changes  to  the  hardware 
design.  The  process  has  certainly  contributed  to  the  overall  ease  of  assembly  that  the  E/F 
has  experienced.  In  an  example  from  the  forward  fuselage,  it  was  estimated  that  VSA 
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reduced  the  number  of  hours  correcting  mismatches11  in  the  forward  fuselage  by  80% 
compared  to  estimates  extrapolated  from  F/A-18C/D  production.  Variation  analysis  and 
IPPD  produced  an  assembly  process  that  was  estimated  to  require  less  than  20%  of  this 
amount.  In  another  example,  the  estimated  requirement  for  labor-intensive  hand 
shimming  was  reduced  87%,  from  75  linear  inches  in  the  original  concept  to  less  than  10 
inches  in  the  final  design. 
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Figure  2.  Sample  VSA  Output 


5.3  Wing  Design 

The  design  of  the  E/F  wing  also  illustrates  the  principle  of  concurrent  development  of 
products  and  processes  and  shows  how  a  management  philosophy  is  reflected  in  changes 
to  hardware.  The  F/A-18C/D  wing  spars  were  machined  in  a  process  that  required  that 
the  part  be  set  in  the  tool  four  separate  times,  as  shown  in  Figure  3. 

The  E/F  wing  IPT  wanted  to  machine  the  spar  using  two  setups  (Figure  4)  to  save  the 
cost  of  setups,  save  machine  time,  and  prevent  defects  that  setups  can  cause.  This  change 
had  an  effect  on  the  design  of  the  wing  skin,  which  attaches  to  the  spar  in  the  wing 
assembly.  In  the  original  C/D  wing,  the  spars  were  slaves  to  the  skin  design.  The  skin 
was  refined  to  maximize  strength  and  minimize  weight.  This  process  left  many  steps  and 
contours  in  the  skin  that  had  to  be  matched  by  the  spars.  Removing  the  steps  would  add 
weight,  but  this  weight  turned  out  to  be  only  a  couple  of  pounds  per  shipset.  The  IPPD 


1 1  Mismatch  means  that  two  parts  in  an  assembly  do  not  line  up  as  they  are  supposed  to,  so  that  where 

two  surfaces  should  be  touching  in  a  joint,  there  is  a  gap.  To  fill  in  the  gaps  in  the  joint,  the  production 
people  have  to  install  shims. 
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management  technique  created  the  environment  that  encouraged  this  tradeoff  study  in  the 
first  place.  The  IPT  organization  put  people  from  the  weight,  strength,  and  producibility 
disciplines  on  the  team  to  make  the  tradeoff  evaluation,  and  it  gave  the  team  authority  to 
implement  the  tradeoff  and  final  recommendation. 


Figure  4.  Process  for  Machining  Wing  Spars  on  the  F/A-18E/F 

In  a  further  refinement  of  the  wing  skin,  this  team  had  to  decide  whether  to 
manufacture  the  composite  skins  with  hard  tooling  on  the  inside  or  on  the  outside  surface. 
Composite  parts  are  typically  cured  with  one  surface  in  contact  with  a  hard  tool,  while  the 
other  surface  is  in  contact  with  soft  materials  and  a  vacuum  bag.  The  surface  cured  in 
contact  with  hard  tooling  will  be  smoother  and  have  less  variability  than  the  bagged 
surface.  The  advantage  of  having  the  smooth  surface  inside  the  wing  is  that  it  improves 
the  fit  between  the  spars  and  skin,  reducing  shimming  and  the  number  of  defects  and 
rework.  The  advantage  of  having  the  hard  tooling  on  the  outside  surface  is  that  the 
smoother  surface  is  desirable  from  a  performance  standpoint.  Using  IPPD  and  the  IPT 
structure,  the  team  determined  that  the  hard  tooling  could  go  on  the  inside  surface,  and 
that  careful  tool  design  could  accommodate  the  performance  requirements  on  the  outside 
surface. 

These  design  tradeoffs  contributed  to  a  wing  spar  that  costs  30%  less  to  manufacture 
when  compared  to  the  cost  of  the  C/D  spar.  In  addition,  the  inner  surface  tooling  and 
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reduced  setup  spars  have  contributed  to  E/F  wing  assemblies  being  completed  with  far 
fewer  defects  than  their  C/D  predecessors. 

5.4  Flight  Control  Computer  System 

The  F/A-18  flight  control  computer  system  consists  of  hardware  and  software 
subsystems  used  to  fly  the  plane.  To  develop  this  computer  system,  the  F/A-18  E/F 
technology  and  product  teams  worked  concurrently,  and  early  in  the  life  cycle,  to  reach 
an  optimal  solution  for  the  overall  program.  One  technology  team  in  particular,  the  Flight 
Control  Flying  Qualities  (FCFQ),  worked  extensively  with  the  product  teams  and  the 
other  technology  teams,  including  Aerodynamics,  Structural  Loads  and  Dynamics,  and 
Materials  and  Structural  Development  teams. 

The  fight  control  computer  system  determines  factors  such  as  how  the  airplane 
responds  to  the  pilot  and  how  to  keep  the  airplane  stable,  and  provides  for  proper  speed 
and  direction.  With  other  teams,  the  FCFQ  team  determined  how  best  to  move  control 
surfaces  such  as  the  wing  flaps  or  tail  in  response  to  the  pilots  commands.  If  the  system 
requirement  is  to  roll  the  plane  180  degrees  per  second  under  certain  flight  conditions,  the 
FCFQ  team  would  develop  preliminary  “control  laws”  or  algorithms  that  eventually  were 
implemented  in  hardware  and  software.  But  these  initial  algorithms  were  first  evaluated 
by  the  other  engineering  teams  to  predict  their  overall  effect.  For  example,  the  Structural 
Loads  and  Dynamics  team  analyzed  the  algorithm  to  predict  the  loads  on  individual 
pieces  of  the  plane,  ensuring  that  the  airframe  could  withstand  the  loads.  If  the  loads 
were  outside  of  the  desired  range,  this  feedback  was  provided  early  to  the  FCFQ  team 
who  was  given  the  opportunity  to  continually  revise  the  algorithm  before  the  hardware  or 
software  was  actually  developed.  Numerous  iterations  and  tradeoffs  were  made  across  the 
teams  to  generate  optimal  algorithms  that  would  be  responsive  to  the  pilot  while  still 
satisfying  the  performance  requirements  for  speed,  weight,  capacity,  etc.  The  use  of 
common  databases  and  analysis  tools — collectively  known  as  Mod  SDF  (Modular  Six 
Degrees  of  Freedom — was  essential  for  coordinating  across  the  teams  and  achieving  a 
balanced  design.  Section  8.3  describes  Mod  SDF  in  greater  detail. 

After  the  technology  teams  performed  their  initial  analysis  and  incorporated  feedback 
from  initial  simulations,  the  hardware  and  software  requirements  were  documented  for 
development.  Only  at  this  point  were  the  algorithms  formally  documented  in  “change 
memos”  which  were  controlled  by  Change  Control  Boards.  The  flight  control 
requirements,  for  example,  were  controlled  by  the  Flight  Control  Change  Board.  The 
interfaces  were  controlled  by  the  Flight  Control  System  Integration  Team  which  consisted 
of  representatives  from  all  subsystems  interfacing  with  the  flight  control  computer. 
Consequently,  the  extensive  analysis  performed  prior  to  formalizing  the  hardware  and 
software  requirements  minimized  both  (1)  the  number  of  change  memos  controlled  by 
these  boards  and  (2)  the  number  of  actual  changes  made  to  the  hardware  and  software 
systems  after  they  had  been  developed. 

Prior  to  the  use  of  IPPD,  this  work  was  done  sequentially  moving  from  one  product 
design  group  to  another.  As  a  result,  delays  and  interdependencies  were  painful  for  the 
program,  and  there  was  little  opportunity  to  change  the  control  algorithms.  In  general, 


15 


the  airframe  was  much  heavier  than  desired:  the  Structural  Loads  and  Dynamics  team 
was  typically  at  the  end  of  the  sequence  and  forced  to  compensate  for  control  algorithms 
that  required  heavy  reinforcements  to  meet  the  loads  on  the  airframe.  Today,  an  iterative 
approach  is  applied  to  the  design  of  these  control  algorithms  to  provide  early  and 
continuous  feedback  across  the  technology  and  product  teams. 


Chapter  6.  Multidisciplinary  Teamwork 


A  third  key  principle  of  IPPD  is  use  of  multidisciplinary  teamwork  through  EPTs. 
Teams  comprising  stakeholders,  including  customers  and  suppliers,  are  central  to  the 
IPPD  process.  By  including  stakeholders  from  various  disciplines  in  the  early  phases  of 
the  design  process,  IPPD  can  reduce  the  number  of  changes  later  in  the  design  process 
when  these  changes  have  a  greater  effect  on  both  cost  and  schedule. 

The  early  structuring  of  the  organization  into  EPTs  was  an  important  and  effective  step 
in  enabling  IPPD  on  the  F/A-18E/F  program.  These  EPTs  brought  together  a  number  of 
functional  disciplines  to  design  and  produce  the  products  and  associated  processes.  The 
EPTs  also  performed  the  necessary  tradeoffs  that  were  required  to  build  an  affordable 
aircraft. 

Assembling  these  teams  early  achieved  more  effective  tradeoffs  but  required  a 
funding  profile  that  included  higher  early  expenditures  than  those  seen  in  previous 
programs — but  with  smaller  expenditures  occurring  later.  The  E/F  program’s  ability  to 
deviate  from  previous  funding  profiles  was  a  benefit  of  the  Navy  program  office’s  close 
and  cooperative  involvement. 

One  benefit  attributed  to  the  use  of  EPTs  on  the  F/A-18E/F  was  the  more  than  a  50% 
reduction  in  the  number  of  Drawing  Change  Notices  or  Engineering  Orders  per 
production  drawing  when  comparing  E/F’s  rate  to  A/B’s  rate: 

•  At  first  flight,  the  E/F  had  less  than  one  Drawing  Change  Notice  or 
Engineering  Order  per  production  drawing. 

•  The  E/F’s  predecessor,  the  F/A-18A/B,  had  well  over  two  changes  per 
drawing  at  the  same  point  in  program. 

The  following  sections  describe  the  origin,  composition,  and  the  powers  of  MDC’s 
multidisciplinary  teams. 

6.1  Evolution  of  the  Team’s  Structure 

Prior  to  the  F/A-18E/F  program,  the  C/D  program  was  organized  by  functional  area. 
The  “hardcore”  engineering  disciplines  (e.g.,  structures,  aerodynamics,  propulsion)  came 
in  first  and  designed  the  aircraft.  Once  the  design  was  complete,  the  manufacturing 
engineers  would  get  involved.  Their  job  was  to  figure  out  how  to  tool,  produce  and 
assemble  the  multitude  of  parts  called  for  in  the  design.  Once  they  had  completed  this, 
the  aircraft  went  into  production. 
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Many  of  the  problems  that  came  up  in  production  were  the  result  of  inadequate  design 
definition.12  And  yet  with  this  organization,  the  engineers  who  designed  the  aircraft  were 
far  removed — both  physically  and  temporally — from  the  production  team.  In  addition, 
the  design  of  the  aircraft  was  not  done  with  ease  of  manufacturing  or  operational 
supportability  as  key  issues. 

Travis  Durand,  an  engineer  and  current  EPT  leader  said  the  following  about  the  old 
way  of  designing  aircraft: 

For  the  C/D,  engineering  and  production  were  in  different  buildings.  The 
engineers  would  take  a  design  to  the  manufacturing  engineers  and  say  “Go 
build  this.”  We’d  toss  the  design  over  the  fence. 

6.2  Functional  Integration  and  IPT  Experimentation 

In  1986,  the  Chief  MDC  Engineer  on  the  F/A-18C/D  program.  Bill  Norman,  led  an 
early  experiment  in  functional  integration  by  having  the  design  engineers  as  part  of  the 
production  team.  These  were  called  “Hornet  Engineering  Action  Teams”  or  HEAT  (i.e., 
an  IPT).  According  to  Travis  Durand,  MDC’s  Level  4  Team  Leader,  F/A-18E/F  Wing 
Team: 


HEAT  was  pretty  hit  or  miss.  We  struggled  for  approximately  18  months. 

Even  though  people  were  on  the  team,  they  weren’t  really  because  the 
team  leader  didn’t  control  their  raises.  That  didn’t  happen  until  1992  with 
E/F.  The  HEAT  team  controlled  their  day-to-day  activities  but  the 
functional  managers  controlled  their  raises. 

The  current  structure  of  IPTs  began  taking  shape  in  1991.  Along  with  defining  the 
team  structure,  a  great  deal  of  effort  went  into  clearly  defining  the  roles  and 
responsibilities  of  each  team  along  with  the  boundaries  between  teams.  These  were 
written  up  in  the  form  of  team  charters.  This  set  the  stage  for  team  leaders  to  be  assigned 
responsibility,  authority,  and  accountability  for  their  product  area,  key  concepts  that  will 
be  revisited  below.  As  the  DoD  1PPD  Handbook  points  out,  “the  best  way  to  minimize 
team  misunderstandings  is  to  document  the  team  dynamics  in  a  team  charter  for  each 
EPT.”  Figure  5  on  the  next  page  is  an  example  MDC  team  charter. 

6.3  Revised  Team  Structure 

The  organizational  structure  that  was  put  into  place  on  the  F-18  E/F  program 
corresponds  to  the  product  hierarchy  as  shown  in  Figure  6: 

•  At  Level  1  is  the  F/A-18  Program  Manager  (Pat  Finneran)  whose 
responsibilities  include  the  A/B,  C/D,  and  E/F  models.  Also  at  Level  1  is  the 
Deputy  Program  Manager  for  the  E/F,  Chuck  Allen. 


12  Discussion  with  Chuck  Allen,  Boeing’s  General  Manager  for  the  F/A-18  program,  June  19,  1908. 
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Establishment  of  the  Office  of  Division  Director  of  F/A-18  Program 

Integrated  Product  Definition 

1.  Purpose: 

To  establish  the  office  and  responsibilities  of  the  F/A-18  Program  Integrated  Product  Definition  (IPD) 
Leader. 

2.  Mission: 

To  lead  all  aspects  of  Integrated  Product  Definition  throughout  the  Define,  Build  and  Support  phases 
of  the  F/A-18  Program.  As  Co-Leader  of  the  Shared  Resources  IPT  Team,  leverage  and  implement 
Enterprise  Best  Practices,  and  aggressively  focus  on  reducing  the  cost  of  our  products  while  meeting 
our  contractual  requirements. 

3.  Responsibilities: 

The  IPD  Leader  is  responsible  to  the  customer  and  program  management  for  production  definition, 
design,  with  shared  responsibility  for  fabrication,  assembly,  delivery  and  fielded  performance  of  the 
F/A  18  Weapon  System. 

This  Position  is  also  responsible  for: 

1.  Allocation  and  flow  down  of  Program  cost,  schedule,  and  technical  requirements  to  the  Shared 
Resources  IPD  teams 

2.  Providing  leadership,  and  technical  direction  and  integration  to  Shared  Resources  IPD  teams. 
Manage  performance  to  plan,  risk  assessments,  trend  analyses,  and  risk  closure  plans,  as 
necessary. 

3.  Establishing  and  implementing  management  metrics  to  provide  visibility  of  cost,  schedule,  and 
technical  performance  of  the  Shared  Resources  IPD  teams. 

4.  Serving  as  the  Principal  engineering  interface  with  the  Naval  System  Command  (Com  NAVAIR 
Sys  Com)  and  the  Naval  Air  Warfare  System  Command  (NAVAIR  Sys  Com)  and  the  NAVAIR 
Program  Office  (PMA-265). 

5.  Partnering  with  the  Production  Operations  to  deliver  quality,  and  affordable  products  on  time 
and  to  identify  opportunities  to  reduce  cost. 

6.  Ensuring  disciplined  and  common  processes  are  implemented  to  meet  contractual  requirements. 

7.  Engaging  and  integrating  internal,  Built  to  Print,  CFE  and  GFE  suppliers  into  the  IPD  teams. 

8.  Serve  as  a  member  of  the  F/A-18  Leadership  Team. 

4.  Accountability  and  Authority: 

The  IPD  Leader  receives  authority  from  and  is  accountable  to  the  Program  Vice  President  for  cost, 
schedule,  and  technical  performance  for  all  product  definition  deliverables.  The  IPD  Leader  is 
authorized  to  make  decisions,  allocate  resources  and  delegate  authority  to  accomplish  program 
contractual  requirements. 

Submitted: _  Approved: _ 

J.A.  Young  P.J.  Finneran 

Division  Director  Vice  President/General  Manager 

F/A- 1 8  Program  Engineering  F/A- 1 8  Program 

Figure  5.  IPT  Charter 
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Courtesy  of  the  McDonnell  Douglas  Corporation. 


Figure  6.  Product  Hierarchy  vs.  IPT  Structure 

•  At  Level  2,  there  is  the  IPT  Manager,  Jim  Young.  He  has  responsibility  for 
the  product  definition  activities.  Also  at  Level  2  are  the  managers  for 
Production,  Support,  and  Business  Operations. 

•  At  Level  3,  under  Jim  Young,  there  are  the  two  major  parts  of  the  aircraft  that 
MDC  is  responsible  for:  the  Airframe  subsystems  and  the  Avionics/Weapons 
Integration. 

•  Level  4  (under  Airframe  subsystems)  includes  five  teams:  Wing/Horizontal 
Tail;  Forward  Fuselage;  Hydromechanical/Mechanical;  Armament,  Crew, 
Electrical;  and  Support  Equipment. 

•  Level  5  (under  Wing/Horizontal  Tail)  includes  three  teams:  Inner/Outer  Wing; 
Wing  Control  Surfaces  (leading,  trailing  edge  flaps,  and  aileron);  and 
Horizontal  Tail. 

This  same  structure  forms  the  basis  for  the  WBS.  As  will  become  clear  below,  one  of 
the  keys  to  the  effective  management  of  this  program  has  been  this  correspondence 
between  the  product  hierarchy,  the  organizational  structure,  and  the  WBS.  Each  of  the 
teams,  right  down  to  Level  5,  has  allocations  of  dollars  (which  the  team  controls),  weight, 
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reliability,  maintainability,  operations  and  support  cost,  electrical  power,  growth  volume 
and  performance.  These  measures  are  reported  by  each  team  on  a  regular  basis 
(depending  on  the  measure,  weekly  or  monthly)  and  are  described  in  Chapter  8, 
Integrated  Information  Environment. 

The  product  and  team  structure  are  not  static  but  continually  evolving.  As  the  F/A- 
18E/F  moves  from  development  into  production,  the  product  definition  teams  are 
becoming  smaller  while  the  production  teams  are  growing.  Both  types  of  teams  are  multi¬ 
disciplinary.  Travis  Durand,  the  Level  4  lead  for  the  Wing  IPT  stated: 

The  guy  who  is  the  team  lead  for  the  production  of  the  wing  was  a 
member  of  my  Product  Definition  Team  six  months  ago.  Now  he  has  his 
own  team  and  we  sit  next  to  each  other  in  the  production  building. 

i 

The  IPT  structure  changes  with  different  phases  of  the  life  cycle,  in  keeping  with  the 
IPPD  tenet  of  early  and  continuous  life  cycle  planning.  At  the  current  time,  the 
Engineering  Manufacturing  and  Development  (EMD)  phase  of  the  life  cycle  is  almost 
finished  while  the  production  phase  is  ramping  up.  The  Level  5  product  definition  teams 
will  soon  be  absorbed  into  Level  4  at  the  same  time  that  the  production  teams  are 
expanding. 

6.4  Empowerment  of  Teams 

Empowerment  of  EPTs  permits  decision  making  to  be  driven  to  the  lowest  possible 
level  commensurate  with  risk.  Moreover,  resources  should  be  allocated  to  levels 
consistent  with  risk  assessment  authority,  responsibility,  and  the  ability  of  people.  The 
team  should  be  given  the  authority,  responsibility,  and  resources  to  manage  its  product 
and  its  risk  commensurate  with  the  team’s  capabilities.  The  authority  of  team  members 
needs  to  be  defined  and  understood  by  the  individual  team  members.  The  team  should 
accept  responsibility  and  be  held  accountable  for  the  results  of  its  efforts.  Management 
practices  within  the  teams  and  their  organizations  must  be  team  oriented  rather  than 
structurally,  functionally,  or  individually  oriented. 

The  words  often  heard  in  reference  to  the  F/A-18E/F  team  leaders  are  “responsibility, 
authority,  and  accountability.”  The  team  leaders  are  responsible  for  delivering  the 
product  and  for  maintaining  frequent  and  open  communication  with  their  NAVAIR 
counterparts.  They  are  given  authority  through  control  of  their  own  budgets.  They  also 
write  performance  appraisals  for  their  team  members.  Every  team  is  allocated  a  budget 
for  dollars,  schedule,  weight,  and  other  relevant  performance  parameters  such  as  power 
and  cooling  requirements.  Accountability  is  achieved  through  the  weekly  reporting  of 
these  measures.  Cost  and  schedule  performance  are  tracked  through  weekly  earned  value 
reports  down  to  the  Level  5  teams. 
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Travis  Durand,  a  Level  4  team  leader,  described  the  leaders’  responsibilities  this 

way: 

Team  leaders  have  to  balance  cost,  quality,  and  schedule.  They  have  to  be 
good  business  folks  as  well  as  engineers.  As  a  Level  4  team  leader,  I  am 
running  my  own  business.  It’s  necessary  to  define  the  business  boundary 
and  what  I  need  to  run  that  business.  We  had  casualties  among  the  Level  4 
and  5  leads  in  the  early  days.  IPT  leaders  have  to  have  a  different  set  of 
skills. 
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Chapter  7.  Proactive  Identification  and  Management  of  Risk 


The  fact  that  the  E/F  was  an  evolution  from  the  earlier  C/D  model  lowered  the  risk 
over  an  entirely  new  design.  In  Jim  Young’s  words,  “We  knew  that  cost,  schedule  and 
weight  were  do-able  because  we  had  experience  on  the  C/D.”  Nevertheless,  building  an 
advanced  fighter/attack  aircraft  is  a  complex  undertaking  where  many  things  can  go 
wrong. 

EPPD  enables  an  organized,  comprehensive,  and  iterative  approach  for  identifying  and 
analyzing  cost,  technical,  and  schedule  risks,  and  instituting  risk-handling  options  to 
control  critical  risk  areas.  IPPD  facilitates  consideration  of  risks  across  functional  areas 
and  exploration  of  alternative  design  concepts.  The  DoD  IPPD  Handbook  states  that 
early  planning  and  aggressive  execution  are  key  to  successful  risk  management.  This 
chapter  describes  MDC’s  risk  management  process  and  examples  of  how  it  is  employed 
to  mitigate  risks  associated  with  suppliers  and  hardware  and  software  integration. 

7.1  MDC’s  Risk  Management  Process 

The  F/A-18  program  defines  risk  as  an  undesirable  situation  or  circumstance  that  has 
both  a  probability  of  occurring  and  a  potential  consequence  to  program  success.  MDC’s 
risk  management  process  offers  an  organized  systematic  decision-making  process  that 
contains  four  key  steps  to  reduce  or  eliminate  risks: 

1.  Risk  identification:  What  can  go  wrong? 

2.  Risk  analysis:  How  big  is  the  risk? 

3.  Risk  planning:  How  can  you  reduce  the  risk? 

4.  Risk  tracking:  How  are  things  going? 

MDC  uses  a  formal  risk  analysis  process  reflective  of  the  process  taught  at  DoD’s 
Defense  Systems  Management  College.  Every  team,  all  the  way  down  to  Level  5,  has  a 
risk  management  plan.  Risks  are  identified  and  then  analyzed  in  terms  of  their  likelihood 
and  consequence.  Both  likelihood  and  consequence  are  rated  on  a  five-point  scale.  High 
and  medium  risks  (Figure  7)  are  required  to  have  a  closure  plan. 

MDC  also  created  the  Systems  Engineering  and  Integration  organization  to  control 
risks  and  manage  the  requirements  allocation  process.  The  organization  included  a  Level 
2  manager,  and  drew  heavily  from  the  lower-level  product  teams.  This  team  took  the 
requirements  defined  in  the  system  specification  and  broke  them  down  for  allocation  to 
the  product  teams.  The  specification  for  aircraft  weight  requirement,  for  example,  would 
become  weight  requirements  for  the  wing  team,  the  forward  fuselage  team,  and  the 
vertical  tail  team.  All  system  requirements,  including  survivability,  reliability,  cost  and 
schedule,  were  allocated  in  this  way.  By  the  time  the  program  reached  Preliminary 
Design  Review,  3,000  specification  paragraphs  had  been  allocated  to  the  product  teams. 
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Legend 


High  risk  -  Disruption  of  the 
plan.  Management  unlikely  to 
alter  outcome. 

Medium  risk  -  Some 
disruption  in  the  plan.  Effective 
management  actions  possible. 
Low  risk-  Little  or  no 
disruption.  Current  approach 


Consequence 


Figure  7.  Risk  Management  Matrix 


Perhaps  the  most  important  aspect  of  the  E/F’s  risk  management  program  is  the 
attitude  toward  risk  that  permeates  the  entire  program,  on  both  the  contractor  and  on  the 
government  side.  Henry  Harchburger,  Level  3  IPT  Leader  for  Airframe  Technology, 
described  this  attitude  as  follows: 

Our  definition  of  good  management  is  recognizing  problems  and  asking 
for  help  early  on.  Anybody  can  define  a  risk.  It’s  okay  to  have  risks,  we 
just  need  a  risk  mitigation  plan.  There  are  three  things  that  are  necessary 
for  an  effective  risk  management  system.  First,  you  want  to  identify 
potential  problems  early.  Secondly,  you’ve  got  to  have  management  that 
doesn’t  shoot  the  messenger.  It’s  critical  that  your  customer  has  the  same 
opinion.  You  have  to  have  people  who  don’t  go  ballistic  when  they  have  a 
problem.  And  third,  you’ve  got  to  have  management  that  will  provide 
help  when  asked.  The  person  at  the  top  has  got  to  have  that  attitude.  And 
in  asking  for  help,  you  have  to  be  able  to  say  what  you  need. 

7.2  Supplier  Risk 

An  example  of  MDC’s  proactive  approach  to  risk  management  is  given  by  its 
handling  of  the  supplier  of  the  landing  gear.  In  November  of  1997,  the  main  landing  gear 
supplier  was  on  the  critical  path  of  being  able  to  deliver  the  first  of  the  low-rate  initial 
production  (LRIP)  aircraft  for  operational  test.  The  scheduled  install  date  for  the  gear 
was  June  1998.  In  the  words  of  Theresa  Carr  of  MDC: 

We  knew  that  this  was  a  schedule  risk  since  the  landing  gear  was  on  the 
critical  path.  We  helped  the  supplier  talk  to  their  suppliers  to  ensure  that 
they  had  the  parts  they  needed.  Our  management  reports  helped  us  stay  on 
top  of  this  because  it  does  network  projections.  The  problem  was 
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addressed  and  tracked  to  closure,  and  an  alternative  installation  plan 
developed  and  implemented  to  support  delivery. 

Because  a  team  could  not  exercise  its  decision  authority  properly  without 
knowing  what  its  specific  requirements  were,  rigorous  allocation  of 
system  requirements  was  essential  to  effective  risk  management.  MDC’s 
philosophy  dictated  that  decisions  were  to  be  pushed  down  in  the 
hierarchy  (empowerment)  while  progress  was  to  be  reported  back  up  using 
metrics  that  were  common  throughout  the  program  (risk  management). 
Obviously,  the  team’s  ability  to  communicate  its  progress  to  upper 
management  also  depended  on  a  clear  understanding  of  goals  and 
expected  progress.  Without  this  reporting,  a  formal  system  of  risk 
identification  would  be  impossible. 


7.3  Hardware  and  Software  Integration  Risks 

Hardware  and  software  integration  risks  were  addressed  early  and  throughout  the  life 
cycle  by  MDC.  During  the  early  stages,  the  teaming  arrangement  was  re-evaluated  to 
give  MDC  more  control  of  the  software  and  the  integration  activities.  Documentation 
and  verification  processes  were  also  defined  early  in  the  life  cycle  to  support  integration. 
When  risks  were  identified  throughout  the  life  cycle,  multidisciplinary  risk  management 
teams  were  established  to  explore  alternative  design  concepts,  evaluate  their  impact,  and 
to  select  the  most  effective  solution.  Another  factor  contributing  to  successful  hardware 
and  software  integration  includes  the  integrated  information  environment  described  in 
Chapter  8. 

During  development  of  the  F/A-18  A/B  and  C/D,  a  decision  was  made  in  technical 
coordination  meetings  with  MDC,  Navy,  and  Lockheed  Martin  to  procure  the  flight 
control  computer  hardware  and  software  from  Lockheed  Martin.  For  the  E/F,  however, 
this  risk  was  reevaluated  early  in  the  life  cycle  when  the  teaming  arrangements  were 
being  negotiated.  There  was  a  formal  “make  versus  buy”  decision  to  determine  if  it 
would  be  more  effective  to  bring  the  software  in-house.  MDC  analysis  identified  that 
bringing  the  software  in-house  would  be  cheaper  with  a  quicker  turn-around  and  would 
offer  more  flexibility.  Thus,  the  decision  was  made  for  MDC  to  develop  the  flight  control 
computer  software  for  the  E/F,  and  Lockheed  Martin  to  supply  the  hardware. 

Hardware  is  not  generally  thought  of  as  “the  problem”  during  integration  because 
most  hardware  problems  are  fixed  by  developing  software  work-arounds.  And  because 
the  original  supplier  often  found  the  software  changes  to  be  out  of  scope  compared  to  the 
original  estimates  used  to  bid  the  contract,  MDC  had  difficulty  negotiating  numerous 
software  changes  with  the  supplier.  It  became  easier  for  MDC  to  implement  the  changes 
in-house  than  to  develop  formal  purchase  orders  and  change  orders  with  the  supplier  to 
implement  changes.  In  addition,  MDC  wanted  to  control  software  to  control  the  cost  and 
schedule  of  integration.  Examples  of  MDC’s  effective  control  of  software  include  the 
“weight  on  wheels”  problem  and  “side  slip”  measurement.  In  both  cases,  MDC  benefited 
from  the  flexibility  of  having  software  developed  in-house  and  exploring  alternative 
design  concepts  to  resolve  system  integration  risks. 
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Weight  on  wheels  switch.  The  “weight  on  wheels”  example  refers  to  a  switch  inside 
the  landing  gear  that  indicates  if  there  is  any  weight  on  the  airplane’s  wheels,  used  to 
designate  whether  the  airplane  is  in  the  air  or  on  the  ground.  A  problem  arose  in  the 
weight  on  wheels  switch  when  the  brake  was  applied  to  the  wheels  after  take-off  but 
before  the  wheels  were  inside  the  wheel  well.  The  brake  caused  a  strut  in  the  landing 
gear  to  compress,  which,  in  turn,  tripped  the  signal  indicating  there  was  weight  on  wheels 
for  a  slight  moment  even  though  the  plane  was  in  the  air  with  no  weight  on  the  wheels. 
There  are  several  functions  whose  operation  are  dependent  on  whether  the  plane  is  in  the 
air  or  on  the  ground.  For  example,  when  the  plane  is  on  the  ground  the  heater  used  for 
anti-icing  does  not  use  heat  since  there  is  limited  air  movement.  But  when  the  plane  is  in 
the  air,  the  heater  must  be  very  hot  to  be  effective  with  increased  air  movement.  If  the 
switch  inaccurately  indicated  the  airplane  was  in  the  air,  the  anti-icing  heater  could 
overheat  a  grounded  plane.  Other  examples  include  the  flight  control  computer 
algorithms  whose  operation  are  also  dependent  on  whether  the  plane  is  in  the  air  or  on  the 
ground.  The  slight  moment  when  the  switch  registered  an  inaccurate  reading  made  a 
difference:  the  pilot  was  prevented  from  using  the  “nose  down  control”  to  land  the 
airplane  because  the  switch  inaccurately  identified  that  the  plane  was  already  on  the 
ground. 

To  address  the  problem  with  the  weight  on  wheels  switch,  MDC  established  a 
multidisciplinary  risk  management  team  with  representatives  landing  gear,  flight  control, 
and  management.  Both  hardware  and  software  solutions  were  considered.  The  hardware 
solution  involved  moving  the  switch  away  from  the  strut  but  this  had  added  cost  plus 
uncertainty:  the  new  location  could  introduce  new  problems  (e.g.,  could  the  bounce  the 
airplane  experiences  on  the  runway  inappropriately  trigger  the  switch  in  the  new 
location?).  The  leading  software  solution  included  the  development  of  an  algorithm  that 
identified  under  what  conditions  the  weight  on  wheel  signal  was  invalid.  For  example, 
“if  the  weight  on  wheels  occurred  shortly  after  take  off,  then  ignore  the  signal.”  The  risk 
management  team  determined  that  the  most  cost-effective  solution  was  to  implement  the 
new  software  algorithm. 

Side  slip  measurement.  The  second  example  of  how  the  F/A-18  program  benefited 
from  MDC’s  control  of  software  was  the  calculation  of  the  side  slip  measurement.  Rather 
than  measure  the  head-on  effect  of  air  current,  side  slip  measures  the  angle  air  makes 
with  the  side  of  the  airplane  which  affects  how  the  airplane  flies.  An  airplane  flies  better 
if  it  accounts  for  side  slip,  though  historically  this  measurement  has  been  too  difficult  to 
obtain.  The  F/A-18  E/F,  however,  made  this  evolutionary  improvement.  MDC  established 
a  risk  management  team  to  evaluate  hardware  and  software  solutions.  The  hardware 
options  required  new  sensors  to  be  mounted  on  the  airplane  to  measure  side  slip,  whereas 
the  software  solutions  took  advantage  of  existing  sensors  to  calculate  side  slip  indirectly 
with  revised  control  laws.  While  the  leading  software  solution  was  less  accurate,  it  was 
determined  to  be  accurate  enough  and  was  less  costly  to  implement  and  maintain  than 
new  hardware  sensors.  As  a  result  of  implementing  the  side  slip  measurement  in 
software  algorithms,  the  E/F  airplane  flies  better  at  high  angles  of  attack,  thus  eliminating 
the  departure  mode  called  “falling  leaf’  which  is  commonly  experienced  in  the  F/A-18  A, 
B,  C,  and  D.  This  occurs  when  the  airplane  goes  out  of  control  like  a  falling  leaf  and 
rocks  side  to  sides  as  it  falls. 
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Up-front”  documents  and  verification.  In  addition  to  maintaining  control  of 
software  development,  integration  risks  were  controlled  by  having  “up-front”  documents 
that  account  for  integration  into  the  system  and  “back-end”  processes  that  verified  the 
subsystems  are  working  together.  The  up-front  documents  decomposed  the  system 
requirements  into  hardware  and  software  specifications,  designs,  and  interfaces.  The 
back-end  verification  processes  tested  each  hardware  and  software  subcomponent  as  well 
as  the  integrated  components  at  the  system  level.  Laboratories  and  simulators  are  used  to 
perform  the  unit  and  integrated  tests  (refer  to  Section  8.3  for  more  details).  The 
following  table  lists  the  key  documents  and  processes  contributing  to  risk  management  of 
hardware  and  software  integration. 


Table  1.  Key  Documents  and  Verification  Processes 


Up-Front  Documents 

Back-End  Verification  Processes 

System  and  Subsystem  Specifications 

Shop  Replaceable  Assembly  Testing 

System  Design  Document 

Computer  Software  Unit  Testing 

Interface  Control  Documents 

Replaceable  Assembly  Testing 

Interface  Definition  Documents 

Computer  Software  Component  Testing 

Hardware  Description  Documents 

Hardware  Configuration  Item  Acceptance  Testing 

Critical  Item  Development  Specification 

Computer  S/W  Configuration  Item  Acceptance  Testing 

Software  Requirements  Specification 

Hardware/software  Integration 

Assembly  Drawings 

Avionics  Integration  Verification  Testing 

Shop  Replacement  Assembly  Fabrication 

Aircraft  Ground  Tests 

Software  Design  Document 

Aircraft  Flight  Tests 

Computer  Software  Unit  coding 

Test  Plans 

Overall,  hardware  and  software  integration  is  viewed  as  a  major  risk  to  the  F/A-18 
program.  But  measures  are  taken  to  identify  and  analyze  the  risks  and  to  implement  risk 
mitigating  solutions.  MDC  uses  in-house  software  development  to  help  control 
integration  risks  as  well  as  up-front  documents  and  back-end  processes. 
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Chapter  8.  Integrated  Information  Environment 


Another  key  principle  of  IPPD  is  the  establishment  of  a  management  system  that 
relates  requirements,  planning,  resource  allocation,  execution,  and  program  tracking  over 
the  product’s  life  cycle.  MDC  did  this  by  creating  HometWEB,  EMICS  (Integrated 
Management  Information  Control  System),  and  Mod  SDF  (Modular  Six  Degrees  of 
Freedom)  to  manage  the  E/F  program. 

MDC  used  commercially  developed  and  widely  distributed  technologies  that  were  not 
available  when  the  C/D  was  developed.  For  example,  electronic  mail,  nearly  unknown  at 
the  time  of  the  F/A-18C/D  development,  was  used  very  heavily  in  the  E/F  program,  with 
some  people  receiving  as  many  as  100  messages  a  day.  Because  team  leaders  had  to 
communicate  with  people  from  many  disciplines,  and  because  these  team  members  were 
in  St.  Louis  (MDC),  Los  Angeles  (Northrop),  Washington  (NAVAIR),  China  Lake 
(NAVAIR),  and  traveling  all  over  the  world,  this  communication  was  essential  to  an 
effective  IPPD  process. 

This  chapter  describes  the  three  MDC  proprietary  integrated  information  systems: 
HometWEB,  IMICS,  and  Mod  SDF. 

8.1  Hornet  WEB 

The  HometWEB  is  a  secure  information  system  hosted  on  MDC’s  intranet  and 
accessible  by  MDC,  the  F/A-18E/F  subcontractors,  and  the  Navy  program  office. 
HometWEB  helps  to  provide  all  stakeholders  real-time  access  to  unclassified  technical 
and  business  information.  It  is  used  to  enhance  workflow  management,  system 
development,  action  item  coordination,  and  electronic  document  sharing.  As  a  secure 
system,  the  data  is  protected  with  adequate  firewalls,  data  integrity,  and  security 
safeguarding  programs. 

Specifically,  the  HometWEB  supports  sharing  of  data  from  both  a  user’s  perspective 
as  well  as  an  author’s  perspective.  With  the  aid  of  a  network  browser  and  document 
viewer,  users  have  access  to  integrated  databases  and  documents  that  contain  the  types  of 
information  depicted  in  Table  2  on  the  next  page. 

The  HometWEB  content  manager,  Kenneth  Kepchar,  said  the  following  about  the 
system  he  helps  to  maintain: 

The  HometWEB  provides  logistic  information  including  publications. 

Users  for  example  can  now  query  databases  on  the  HometWEB  intranet  to 
identify  what  support  is  required  for  a  particular  F/A-18  engine.  The  user 
would  receive  lists  and  photographs  of  the  engine’s  support  gear.  In  the 
old  days  this  information  was  contained  in  12-inch  thick  binders. 
HometWEB  now  puts  this  information  on-line,  making  the  data  more 
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accessible,  easier  to  maintain,  and  more  current.  Logistic  support  is  now 
one  of  the  web  sites  most  often  queried. 

Table  2.  Example  of  Hornet  WEB  Process  Links 


HometWEB 

Sites 

Examples 

Business  Acquisition 

Contract  documents,  specifications,  new  product  development,  Navy 
programs,  international  programs 

Program  Management 

Configuration  management,  data  management,  human  resources,  program 
directives,  measurement  program,  metrics 

Systems  Engineering 

CALS/CITIS  information,  reliability  and  maintainability,  survivability,  risk 
management,  supportability  assurance,  Management  Plan,  Readiness 

Program 

Product  Development 

IPTs,  controls  and  displays,  flight  controls,  transition 

Verification 

Flight  limitations,  operational  evaluation  preparedness 

Production 

Quality  assurance,  supplier  management  and  procurement,  training  systems, 
variability  reduction 

Product  support 

Support  engineering,  publications,  technical  manual,  ILS  management  team 
interface,  maintenance  engineering  investigations,  supportability  assurance 
readiness  program 

Key:  CALS  Continuous  Acquisition  and  Life-Cycle  Support 

CITIS  Contractor  Integrated  Technical  Information  Service 
ILS  integrated  logistics  support 


HometWEB  also  provides  authors  of  data  files  access  to  standard  development  tools 
including  editors,  document  converters,  databases,  compilers,  and  other  utilities.  This 
information  system  has  helped  to  facilitate  IPPD  practices  by  making  key  data  accessible 
across  the  F/A-18  program. 

8.2  IMICS 

In  addition  to  the  HometWEB,  there  is  probably  no  technology  or  software  that  had 
more  impact  on  the  program  than  IMICS.  Whenever  F/A-18E/F  success  factors  are 
discussed  by  either  contractor  or  government  managers,  IMICS  is  inevitably  near  the  top 
of  the  list.  In  the  program’s  first  award  fee  letter  from  the  government,  the  system  was 
cited  as  a  major  strength  of  the  program.  The  team  that  created  the  system  has  received 
the  highest  awards  at  both  the  company  and  corporate  levels  within  MDC.  Most 
importantly,  the  system  is  widely  noted  as  being  critical  to  the  program’s  successful 
pursuit  of  two  key  IPPD  tenets:  open  communication  and  rigorous  risk  management. 
These  priorities  were  demanded  by  the  Navy  in  response  to  the  failure  of  the  A- 12 
program,  and  MDC  formally  promised  them  from  the  very  start  of  the  F/A-18E/F 
program. 
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To  meet  these  objectives  of  open  communication  and  rigorous  risk  management, 
high-level  program  officials  both  inside  and  outside  of  MDC  had  to  effectively  monitor 
the  program  and  communicate  its  progress  even  while  decision  authority  was  being 
pushed  to  the  lower-level  IPTs.  This  was  accomplished  by  first  allocating  the 
requirements  as  far  down  as  Level  5  teams,  as  described  previously  in  this  study.  After 
allocating  the  requirements,  the  teams  had  to  be  able  to  systematically  measure  their 
progress  against  these  requirements  and  report  this  progress  to  management.  The  system 
had  to  be  constructed  so  that  the  measurements  were  easily  understood  by  a  wide  range 
of  people  no  matter  what  part  of  the  program  the  reports  described. 

The  DoD  IPPD  Handbook  recommends  that  IPTs  develop  technical  and  business 
performance  measurement  plans  with  appropriate  metrics  to  monitor  the  effectiveness 
and  degree  of  anticipated  and  actual  achievement  of  technical  and  business  parameters. 
F/A-18E/F  IPTs  created  specific  metrics  for  schedule,  cost  and  risk  status,  as  well  as  for 
technical  performance.  Schedule  and  cost  results  were  reported  weekly  while 
supportability  and  technical  performance  parameters — such  as  reliability,  maintainability, 
weight,  and  RCS — were  reported  monthly.  IMICS  provided  snapshots  in  time  as  well  as 
trend  analysis.  Separate  charts  also  allowed  IPT  leaders  to  “ask  for  help”  when  some 
performance  parameter  was  not  progressing  as  planned. 

Early  in  the  program,  the  customer  criticized  MDC  for  including  too  many  subjective 
measures  of  progress  in  their  program  reporting.  MDC  responded  aggressively,  and 
within  several  months  had  created  objective  measures  for  97%  of  the  work  packages  of 
longer  than  14-weeks  duration.  Overall,  less  than  20%  of  the  tracked  items  use  level  of 
effort  as  a  measure  of  progress. 

The  objective  measures  MDC  created  reached  impressive  levels  of  detail,  often 
becoming  templates  that  were  to  be  used  by  all  teams,  to  ensure  consistency  of  reporting. 
For  example,  the  template  to  measure  the  progress  of  a  structural  assembly  layout  (ALO) 
was  two  pages  long.  It  listed  26  separate  items  that  must  be  completed  before  the  ALO 
could  be  considered  20%  complete,  and  28  more  that  must  be  achieved  to  reach  the  70% 
complete  milestone.  Armed  with  their  allocated  requirements,  and  templates  for 
reporting  progress  against  the  requirements,  IPT  leaders  knew  what  was  to  be  reported 
every  week,  and  how  their  performance  was  being  measured. 

IMICS  made  this  reporting  useful  to  management  by  pushing  information  up  the 
organization  in  a  system  that  was  consistent  in  its  presentation,  but  flexible  in  the  level  of 
detail  presented.  IMICS  took  data  for  all  metrics  and  at  all  levels,  and  rolled  them  up  at 
whatever  level  a  manager  wished  to  see  them.  If  interested  in  weight,  for  example,  a 
manager  could  see  the  overall  aircraft  weight  progress  and  trends.  He  or  she  could  then 
“drill  down”  to  lower  levels  and  see  how  weight  was  progressing  in  the  Level  4  wing 
team,  or  even  in  the  Level  5  control  surfaces  team.  Additional  IMICS  measures  include 
cost  and  schedule  performance  indices  as  follows: 

•  Budgeted  cost  of  work  scheduled  •  Cost  variance 

•  Budgeted  cost  of  work  performed  •  Cost  performance  index 

•  Actual  cost  of  work  performed  •  Budget  at  completion  (dollars) 
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•  Schedule  variance  •  Estimate  at  completion  (dollars) 

•  Schedule  performance  index  •  To  complete  performance  indices 

Managers  at  MDC  and  in  the  government  had  access  to  IMICS  information  at  all 
levels  of  granularity  as  it  was  updated  each  week.  Items  falling  behind  their  goals  were 
easily  identified,  and  progress  against  corrective  action  was  easily  tracked.  When  an 
item  demanded  upper  level  attention,  Captain  Joseph  W.  Dyer,  the  government  program 
manager,  and  Mike  Sears,  the  MDC  program  manager,  could  each  bring  the  same  data  up 
on  their  screens  as  they  discussed  the  problem.  In  more  routine  situations,  the  metrics 
and  the  presentation  charts  provided  a  ready  format  for  the  weekly  management  meetings 
held  at  MDC  and  for  progress  reports  to  officials  outside. 

Because  IMICS  organized  a  large  amount  of  data  into  usable  form,  and  was  widely 
used  and  distributed  both  within  and  outside  the  government,  it  made  the  progress  of  the 
program  understandable  to  a  wide  number  of  people.  This  wide  communication,  in  turn, 
allowed  the  teams  to  effectively  identify  and  address  areas  that  put  the  program’s 
objectives  at  risk.  Because  IMICS  was  so  effective,  it  has  been  widely  praised  for  its 
contribution  to  the  F/A-18E/F,  and  is  now  being  applied  to  other  MDC  programs. 

8.3  Mod  SDF 

MDC  used  common  databases  and  analysis  tools,  known  collectively  as  Mod  SDF,  to 
facilitate  the  exchange  of  information  across  the  product  and  technology  teams  to 
produce  balanced  requirements  and  designs.  Table  3  contains  a  list  of  the  Mod  SDF 
databases  and  tools  used  by  these  engineering  teams. 

Table  3.  Mod  SDF  Databases  and  Analysis  Tools 


Mod  SDF 

Technology  Teams 

Flight  Control  Structural  Materials  & 

Flying  Loads  &  Structural 

Aerodynamics  Qualities  Dynamics  Development 

Databases 

Aero  Database 

Control  Laws 

Loads  Database 

Materials  Database 

Analysis  Tools 

Mission 

Performance 

Flying  Quality 
Criteria 

Design  Loads 

Design  Allowables 

Carrier  Suit 
Performance 

Control  Laws 

Dynamic 

Environment 

Composite 

Allowables 

Weapon 

Separation 

Requirements 

Aeroelastic 

Stability 

Requirements 

Full  Scale  Test 
Requirements 

In  addition  to  the  tools  listed  in  Table  2,  the  technology  teams  relied  heavily  on  the 
use  of  simulations  supported  by  Mod  SDF  to  analyze  the  requirements,  software  code, 
and  the  integrated  subsystems.  As  in  the  case  of  the  flight  control  computer  system. 
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simulations  were  used  to  conduct  several  levels  of  testing  to  ensure  the  Assembly  code 
and  flight  hardware  were  operating  correctly. 

•  First,  fully  automated  software  testing  was  performed  to  compare  the  results 
of  the  Mod  SDF  simulated  software  with  that  of  the  Assembly  code  operating 
in  the  Flight  Control  Computer.  The  software  developers  did  this  to  ensure 
that  their  Assembly  programs  produced  the  same  expected  results  as  the 
simulations  which  were  used  to  optimize  the  engineers’  algorithms. 

•  Second,  the  flight  control  computer  with  the  Assembly  code  was  tested 
together  with  the  mission  computer  and  with  simulations  of  other  subsystems 
in  an  extensive  series  of  manual  and  automated  tests. 

t 

•  Third,  this  same  configuration  was  tested  in  the  Manned  Flight  Hardware 
Simulator. 

Overall,  these  simulations  were  performed  with  progressing  levels  of  difficulty  and 
helped  to  test  the  integrated  subsystems  in  a  dynamic,  interactive  environment. 


Chapter  9.  Conclusions 


The  contractor  reported  that  the  F/A-18E/F  program’s  low-risk  philosophy  and  cost 
consciousness  contributed  to  its  success  in  achieving  or  exceeding  cost  and  schedule 
goals.  The  EMD  program  met  the  budgeted  goal  of  $4.88  billion  (Fiscal  Year  1990 
dollars).  The  first  flight  occurred  a  month  ahead  of  schedule,  and  was  performed  with  an 
air  vehicle  that  was  well  below  its  specified  weight.  The  flight  test  program  had 
completed  3,000  hours  and  2,000  flights  by  June  of  1998,  and  has  completed  75%  of  the 
EMD  program.13  The  program  has  entered  LRIP,  with  62  aircraft  under  contract,  and  the 
first  production  aircraft  scheduled  for  delivery  in  January  1999. 

Though  the  program  is  still  in  EMD,  MDC  has  reported  projected  improvement^  in 
the  reliability  and  maintainability  measures  of  the  F/A-18E/F  as  compared  to  its 
predecessors.  In  response  to  Fleet  questions  during  a  1998  visit  to  the  Navy  aircraft 
carrier,  the  USS  Abraham  Lincoln,  senior  MDC  officials  reported  to  the  Navy  the 
following: 

•  The  projected  reliability  or  Mean-Flight-Hours-Between-Failure  of  the  E/F 
model  compares  favorably  with  the  current  F/A-18C/D  fleet  with  an 
improvement  of  up  to  25%. 

•  The  “Organizational”  Level  Scheduled  and  Unscheduled  Maintenance  Man 
Hours/Flight  Hour  is  expected  to  improve  by  over  40%  when  compared  to  the 
current  C/D  Fleet. 

The  F/A-18E/F  design  reflects  the  multi-role  demands  that  will  be  placed  on  it  and 
the  low-risk  programmatic  environment  in  which  it  was  created.  The  contractor  reported 
improvements  over  the  F/A-18C/D  in  nearly  every  measure,  but  it  is  an  evolutionary 
aircraft  with  less  ambitious  goals  than  the  failed  A-12,  A-X,  and  NATF.  Examples  of  E/F 
improvements  include: 

•  Improving  the  F/A-18C/D’s  range  by  between  20  and  50%,  depending  on  the 
mission  profiles  and  store  combinations  used  for  comparison. 

•  Improving  survivability  relative  to  the  C/D  by  employing  limited  RCS  control 
features,  by  adding  advanced  defensive  systems,  and  by  reducing  the  aircraft’s 
vulnerable  area. 

•  Providing  11  stations  for  carriage  of  weapons,  fuel,  and  other  stores, 
compared  to  the  C/D’s  9  stations. 


13  For  more  information,  see  the  Hornet  Hyperlink  Web  site  at  http://pma265.navair.navy.mil/reports/ 
1 998/98070  l.html. 
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•  Providing  the  capability  to  bring  3,000  pounds  more  of  these  stores  back  to 
the  carrier,  greatly  improving  mission  flexibility. 

•  Providing  17  cubic  feet  of  empty  internal  volume  to  accommodate  additional 
avionics  packages  or  other  upgrades,  allowing  for  future  capability 
improvements. 

MDC  acknowledges  five  principles  of  BPPD  as  being  largely  responsible  for  the  F/A- 
18E/F  program’s  success  as  follows. 

Customer  Focus 

As  seen  during  the  “Twelve  days  of  August,”  the  customer  and  the  contractors 
worked  together  to  define  requirements  and  make  necessary  tradeoffs.  Communications 
between  MDC  and  the  customer  were  frequent  and  open,  including  daily  contact.  The 
F/A-18E/F  became  an  affordable  evolution  from  the  C/D  and  not  another  gold-plated 
program. 

Concurrent  Development  of  Products  and  Processes 

This  case  study  includes  several  examples  of  the  concurrent  development  of  product 
and  processes.  By  tailoring  the  design  of  the  E/F  to  take  maximum  advantage  of 
improved  manufacturing  processes,  the  E/F  consists  of  42%  fewer  parts  than  the  C/D 
even  though  it  is  25%  larger.  Reducing  the  number  of  parts  reduced  costs.  Moreover,  by 
creating  production  processes  and  hardware  designs  simultaneously  and  carefully 
analyzing  the  sources  of  variation  in  the  process,  the  F/A-18E/F  program  was  able  to 
reduce  production  costs  and  create  production  processes  that  reduced  defects  and  rework. 
As  an  example,  concurrent  design  tradeoffs  resulted  in  E/F  wing  spars  of  higher  quality 
and  costing  30%  less  than  the  C/D  wing  spars.  Numerous  iterations  and  early  tradeoffs 
made  while  designing  the  flight  control  computer  system  resulted  in  fewer  requirements 
changes  and  change  memos. 

Multidisciplinary  Teamwork 

Several  factors  contributed  to  successful  multidisciplinary  teamwork  on  the  F/A- 
18E/F  program.  Dollars,  schedule,  and  technical  parameters  were  allocated  down  to 
Level  5  in  the  WBS.  In  addition  to  having  control  over  their  own  budgets,  team  leaders 
had  the  appropriate  authority  to  get  jobs  done.  Weekly  reporting  of  metrics  kept  teams 
informed  and  accountable.  Organizational  structure  mirrored  product  structure,  with  the 
result  that  the  product  was  broken  down  into  small  enough  pieces  to  be  developed  by  a 
single  team.  Finally,  skills  of  the  team  leaders  were  critical  to  the  success  of  teams. 

Proactive  Identification  and  Management  of  Risk 

The  fact  that  the  E/F  evolved  from  the  C/D  lowered  the  risk  of  the  program  from  the 
outset.  However,  proactive  identification  and  management  of  risk  were  still  essential  to 
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the  ultimate  success  of  the  program.  Proactive  identification  was  accomplished  through 
the  overarching  management  philosophy  of  recognizing  problems  early  on  and  asking  for 
help.  Weekly  reporting  was  instrumental  in  this  process.  Once  system  requirements  were 
allocated  to  teams,  teams  used  MDC’s  formal  risk  management  process  to  develop  risk 
management  plans  that  identified  risks  and  then  analyzed  them  in  terms  of  their 
likelihood  and  consequence.  Included  in  the  risk  management  plans  were  alternative 
design  approaches  evaluated  by  multidisciplinary  teams  to  identify  the  most  effective 
solution.  This  process  was  applied  to  the  analyses  of  the  weight  on  wheels  switch  and  the 
side  slip  measurement. 

Integrated  Information  Environment 

The  integrated  information  environment,  examples  of  which  were  the  Hornet W]EB, 
IMICS,  Mod  SDF,  and  electronic  mail,  was  critical  to  the  program’s  success  by  enabling 
open  communication  and  rigorous  risk  management.  HometWEB,  a  secure  information 
system,  enhanced  workflow  management,  system  development,  electronic  document 
sharing,  and  scheduling  and  milestone  planning  by  making  key  data  accessible  across  the 
F/A-18E/F  program.  IMICS  was  a  standard  system  for  measuring  and  reporting  progress 
at  all  levels.  Mod  SDF,  a  collection  of  common  databases  and  analysis  tools,  was  used  to 
facilitate  exchange  of  engineering  information  across  development  teams.  Moreover, 
managers  at  all  levels  of  both  MDC  and  the  government  had  access  to  HometWEB, 
IMICS,  and  Mod  SDF. 


For  additional  information  concerning  IPPD  and  DoD  acquisition  case 
studies,  refer  to  the  Office  of  the  Deputy  Director,  Systems 
Engineering  in  the  Department  of  Test,  Systems  Engineering  and 
Evaluation  under  the  Office  of  the  Under  Secretary  of  Defense  for 
Acquisition  and  Technology. 

The  Office  of  the  Deputy  Director,  Systems  Engineering  can  be 
reached  at  the  Pentagon,  Room  3D-1075,  Washington,  DC  20301- 
3110,  (703)  695-2300,  as  well  as  through  its  Web  site  at 
http://www.acq.osd.mil/te/programs/se/index.htm 
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Chapter  10.  Discussion  Items 


The  following  questions  are  provided  to  stimulate  the  discussion  and  understanding 
of  the  use  of  IPPD  on  the  F/A-18  E/F  program.  Appendix  A  contains  examples  of 
responses  to  each  question. 

1.  What  technique  was  used  to  ensure  stakeholder  issues  were  addressed  early  in 
the  life  cycle? 

2.  Flow  did  the  F/A-18  program  benefit  from  the  Integrated  Test  Team? 

3.  How  were  benefits  achieved  from  concurrent  development  of  products  and 
processes? 

4.  How  did  the  F/A-18  program  structure  its  Integrated  Product  Teams? 

5.  What  barriers  did  the  program  run  into  when  establishing  the  DPT  structure  and 
how  did  the  program  resolve  them? 

6.  How  did  MDC  management  empower  the  IPT  leaders  and  team  members? 

7.  How  did  the  composition  of  the  teams  change  throughout  the  life  cycle? 

8.  What  are  the  four  key  steps  used  in  the  proactive  risk  management  program? 

9.  What  analytical  and  management  techniques  were  used  to  control  risk? 

10.  How  did  empowerment  contribute  to  the  risk  management  practices? 

11.  How  did  the  F/A-18  ensure  everyone  had  immediate  access  to  the  most  current 
information  for  decision  making? 

12.  What  methods  were  used  to  support  hardware  and  software  system  integration? 

13.  What  approach  did  the  F/A-18  take  to  monitor  and  report  progress? 

14.  Given  the  IPPD  approach  was  used  on  the  F/A-18  E/F  program,  what 
distinguishes  the  program  as  a  management  success? 
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Appendix  A. 

Example  Responses  to  Discussion  Items 

Chapter  10  of  this  paper  contains  a  list  of  questions  designed  to  stimulate  discussion 
among  students  of  the  DoD  acquisition  process.  Following  are  example  responses  which 
can  be  used  to  initiate  or  guide  the  discussion. 

1.  What  technique  was  used  to  ensure  stakeholder  issues  were  addressed  early  in 
the  life  cycle? 

Early  in  the  FA-18E/F  life  cycle,  during  the  “12  days  of  August,”  stakeholder 
teams  from  MDC,  Northrop,  General  Electric,  and  the  customer  (Navy)  worked 
together  to  define  requirements  and  analyze  tradeoffs.  This  was  done  against  a 
backdrop  of  high-level  objectives  that  included  more  range,  better  survivability, 
more  “bring  back,”  more  carriage  capability,  more  growth  capability  built  in, 
and  a  Congressional  mandate  that  cost  of  the  E/F  not  exceed  cost  of  the  C/D  by 
more  than  25%. 

2.  How  did  the  F/A-18E/F  program  benefit  from  the  Integrated  Test  Team? 

The  Integrated  Test  Team  benefited  the  F/A-18  program  through  early  life  cycle 
focus,  concurrent  development  of  products  and  processes,  and  customer  focus. 
An  early  life  cycle  focus  enabled  the  ITT  to  reconsider  traditional  testing 
practices  and  redesign  them  so  that  the  contractor  and  government  tested  the 
aircraft  concurrently.  This  new  process  was  more  effective  in  that  it  reduced 
DT&E  from  four  years  to  three  years.  Moreover,  early  involvement  of  the 
OT&E  pilot  reduced  costs  because  the  OT&E  pilot  was  able  to  recommend 
changes  earlier  when  they  were  less  expensive  to  make. 

3.  How  were  benefits  achieved  from  concurrent  development  of  products  and 
processes? 

MDC  reported  that  concurrent  development  of  products  and  processes  resulted 
in  lower  costs  and  improved  quality  due,  in  part,  to  a  reduction  in  the  number  of 
parts,  optimization  of  the  wing  spar  machine  process,  and  use  of  Variation 
Simulation  Analysis.  Specifically,  the  E/F  airframe  had  42%  fewer  parts  than 
the  C/D,  which  reduced  costs  of  part  assembly,  such  as  tooling,  fastener 
installation  and  inspection,  as  well  as  part  tracking  and  procurement  costs. 

Streamlining  the  wing  spar  design  to  require  fewer  cuts  also  reduced  the  cost  of 
setups,  saved  machine  time,  and  prevented  defects  that  setups  can  cause. 

Finally,  by  creating  the  production  processes  and  hardware  designs 
simultaneously,  and  carefully  analyzing  the  sources  of  variation  using  Variation 
Simulation  Analysis,  the  E/F  program  was  able  to  reduce  defects  and  rework 
which,  in  turn,  reduced  costs  and  improved  quality. 
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4.  How  did  the  F/A-18  program  structure  its  Integrated  Product  Teams? 

The  F/A-18  program  structured  its  Integrated  Product  Teams  according  to  the 
Work  Breakdown  Structure  (WBS),  a  product  hierarchy  consisting  of  five 
levels.  By  doing  so,  the  relationship  between  IPTs  was  clear,  and  team  members 
had  visibility  for  how  their  IPT  contributes  to  the  overall  program.  Overall  team 
membership  was  based  on  multifunctional,  multidisciplinary,  and  stakeholder 
involvement. 

5.  What  barriers  did  the  program  run  into  when  establishing  the  IPT  structure  and 
how  did  the  program  resolve  them? 

The  initial  IPT  structure  was  unsuccessful  because  it  lacked  authority  and 
accountability.  For  example,  team  leaders  did  not  control  members’  raises.  This 
was  resolved  by  defining  and  documenting  team  structure,  roles,  and 
responsibilities  in  team  charters. 

6.  How  did  MDC  management  empower  the  IPT  leaders  and  team  members? 

MDC  management  empowered  IPT  leaders  and  team  members  by  establishing 
team  charters  that  define  the  role  and  responsibility  of  each  team  as  well  as 
boundaries  between  teams.  In  this  way,  team  leaders  were  assigned 
accountability,  authority,  and  responsibility.  Each  team  was  allocated  a  budget 
for  dollars,  schedule,  weight,  and  other  relevant  performance  parameters. 
Accountability  was  achieved  through  the  weekly  reporting  of  these  measures. 
This  empowerment  of  IPTs  permitted  decision  making  to  be  driven  to  the  lowest 
possible  level  commensurate  with  risk. 

7.  How  did  the  composition  of  the  teams  change  throughout  the  life  cycle? 

IPTs  evolved  throughout  the  life  cycle  to  ensure  continuous  focus  on  the  life 
cycle  and  appropriate  stakeholder  involvement.  For  example,  as  the  product 
moved  from  development  into  production,  the  number  of  members  on  the  IPT 
representing  requirements  definition  decreased  but  the  number  of  members 
representing  production  increased. 

8.  What  are  the  four  key  steps  used  in  the  proactive  risk  management  program  ? 

(1)  Risk  identification:  What  can  go  wrong? 

(2)  Risk  analysis:  How  big  is  the  risk? 

(3)  Risk  planning:  How  can  you  reduce  the  risk? 

(4)  Risk  tracking:  How  are  things  going? 
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9.  What  analytical  and  management  techniques  were  used  to  control  risk? 

To  help  control  risk,  MDC  used  the  analytical  techniques  of  system 
decomposition  and  a  risk  management  matrix  categorizing  likelihood  and 
consequences  of  each  risk.  One  management  technique  was  to  create  the 
Systems  Engineering  and  Integration  organization  to  control  risks  and  manage 
the  requirements  allocation  process. 

10.  How  did  empowerment  contribute  to  the  risk  management  practices? 

By  empowering  individuals  at  all  levels  to  recognize  risks  and  to  ask  for  help 
early  on,  MDC  created  an  environment  open  to  risk  identification. 
Management’s  attitude  was  that  effective  risk  management  depends  on 
identifying  potential  problems  early,  not  penalizing  people  for  identifying  risks, 
and  providing  help  when  asked. 

11.  How  did  the  F/A-18E/F  ensure  everyone  had  immediate  access  to  the  most 
current  information  for  decision  making? 

HometWEB,  a  secure  information  system  on  MDC’s  intranet  and  accessible  by 
the  MDC  teams,  the  F/A-18  subcontractors,  and  the  Navy  program  office, 
provided  all  stakeholders  with  real-time  access  to  technical  and  business 
information.  It  enhanced  workflow  management,  system  development,  action 
item  coordination,  and  electronic  document  sharing.  It  also  provided  users  with 
standard  development  tools  such  as  editors,  document  converters,  databases, 
compilers,  and  other  utilities. 

12.  What  methods  were  used  to  support  hardware  and  software  system  integration? 

The  purpose  of  integration  is  to  ensure  system  elements  function  together  as  a 
whole  to  achieve  the  program’s  requirements.  Integration  primarily  involves 
identifying,  defining,  and  controlling  subsystem  interfaces  as  well  as  verifying 
system  functions.  On  the  F/A18-E/F,  integration  activities  began  early  when  all 
engineering  disciplines  could  influence  the  requirements  and  interfaces  and 
define  “up-front”  documentation  and  “back-end”  processes.  System  interfaces 
and  requirements  were  formally  documented  and  controlled  through  Change 
Control  Boards.  In  the  case  of  the  Flight  Control  Computer,  integration  was 
further  supported  with  the  formation  of  a  Flight  Control  System  Integration 
team  consisting  of  representatives  from  all  subsystems  interfacing  with  the 
Flight  Control  Computer. 

With  a  change  in  the  original  teaming  agreement,  MDC  sought  control  of 
software  development  to  better  control  the  cost  and  schedule  of  integration. 
MDC  benefited  from  having  the  flight  control  computer  software  developed  in- 
house  because  it  also  provided  the  flexibility  to  evaluate  alternative  design 
approaches  and  to  implement  the  most  effective  solutions  which  were  usually 
done  with  added  software  as  opposed  to  hardware  (e.g.,  weight  on  wheels 
switch,  side  slip  measurement). 
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In  addition.  Mod  SDF  provided  an  integrated  information  environment 
facilitating  the  analysis  and  optimization  of  requirements  across  the  engineering 
teams.  In  the  case  of  the  flight  control  computer  system,  numerous  iterations 
and  tradeoffs  were  made  between  the  engineering  teams  to  ensure  that  all 
system-wide  design  impacts  were  considered  early  in  the  life  cycle  and  that  the 
tradeoffs  resulted  in  the  best  solution  for  the  aircraft  as  a  whole. 

Verification  was  done  with  extensive  use  of  analysis  and  simulation  models 
such  as  those  supported  by  the  Mod  SDF.  Simulations  were  used  to  evaluate  the 
Flight  Control  Computer,  Mission  Computer,  and  other  subsystems  in  an 
extensive  series  of  manual  and  automated  tests.  Fully  integrated  hardware  and 
software  systems  were  also  used  to  perform  manned  flight  simulations  with 
pilots. 

13.  What  approach  did  the  F/A-18E/F  take  to  monitor  and  report  progress? 

Once  the  F/A-18  system  was  decomposed,  and  requirements  were  allocated  as 
far  down  as  Level  5  of  the  WBS,  the  Integrated  Management  Information 
Control  System  (IMICS)  was  critical  to  measuring  and  reporting  progress  to 
management.  IMICS  took  data  for  all  metrics  and  at  all  levels,  and  presented 
them  at  whatever  level  of  granularity  a  manager  wished  to  see  them.  It  thus 
facilitated  accurate  progress  measurement,  open  communication,  and  rigorous 
risk  management  on  the  F/A-18  program. 

14.  Given  the  1PPD  approach  was  used  on  the  F/A-18E/F  program,  what 
distinguishes  the  program  as  a  management  success? 

As  reported  by  the  MDC  contractor,  the  F/A-18E/F  was  able  to  meet  its  budget 
ahead  of  schedule  with  improved  reliability,  maintainability,  and  capability  over 
the  C/D  in  areas  of,  for  example,  range,  survivability,  flexibility,  weight,  and 
expandability. 
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Acronyms 


ALO 

Assembly  Layout 

CALS 

Continuous  Acquisition  and  Life-Cycle  Support 

cms 

Contractor  Integrated  Technical  Information  Service 

DT&E 

Developmental  Test  and  Evaluation 

EMD 

Engineering  Manufacturing  and  Development 

FCFQ 

Flight  Control  Flying  Qualities 

ILS 

Integrated  Logistics  Support 

IPPD 

Integrated  Product  and  Process  Development 

IMICS 
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